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Abstract 

When  it  comes  to  security  protocol  analysis,  the  devil  lies  in  the  detail  ...  or  more  precisely  in  how  they  are  expressed. 
This  report  collects  the  formal  definition  of  MSR  2.0,  an  unambiguous,  flexible,  powerful  and  relatively  simple  specification 
framework  for  cryptographic  security  protocols.  MSR  2.0  is  a  strongly  typed  multiset  rewriting  language  over  first-order 
atomic  formulas.  It  uses  existential  quantifiers  to  model  the  generation  of  fresh  data  and  memory  predicates  to  encode  systems 
consisting  of  a  collection  of  coordinated  subprotocols.  Its  typing  infrastructure,  based  on  the  theory  of  dependent  types  with 
subsorting,  supports  type-checking  and  data  access  validation,  a  static  check  that  is  shown  to  be  intimately  connected  to  the 
Dolev-Yao  model.  We  show  that  MSR  2.0’s  dynamic  semantics  preserves  typing  and  data  access  validy.  We  also  provide 
a  formal  proof  that  the  Dolev-Yao  intruder  can  emulate  any  attacker  that  can  be  specified  within  the  Dolev-Yao  model  of 
security,  a  fundamental  assumption  of  many  verification  tools  that  however  had  never  been  proved  before.  We  conclude 
with  three  specifications  of  increasing  sophistication,  starting  with  the  classic  Needham-Schroeder  public-key  authentication 
protocol  and  ending  with  the  complex  manipulations  involved  in  the  OFT  group  key  management  protocol. 
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1  INTRODUCTION 


1  Introduction 

While  early  work  on  comprehending  cryptographic  protocols  goes  back  to  the  late  1970s  and  early  1980s  (52l  l44l.  the 
systematic  study  of  these  security  artifacts  emerged  as  a  recognizable  subfield  within  computer  science  in  the  mid- 1990, 
with  the  widespread  adoption  of  the  Internet.  Since  then,  there  have  been  significant  advancements  both  in  the  foundational 
understanding  of  cryptographic  protocol  security  (46),  and  in  the  development  of  practical  tools  that  can  verify  not  just  the 
toy  protocols  of  the  1990s  but  commercial  protocols  m,  and  not  only  convenient  abstractions  as  embodied  by  the  Dolev- 
Yao  model  (441.  but  the  bitstring  transformations  performed  by  actual  cryptographic  primitives  in  what  is  now  known  as  the 
computational  model  (2j  5  9  I5.40|. 

Up  to  the  late  1990s,  protocols  were  described  in  English  by  and  large,  which  often  led  to  ambiguities.  Understandably, 
their  verification  was  in  its  infancy.  Towards  the  very  end  of  that  decade,  several  groups  of  researchers  (UISllSZl  started 
proposing  formal  languages  in  which  to  describe  a  protocol  unambiguously,  a  necessary  basis  for  robust  verifications.  This 
report  focuses  on  one  of  these  efforts,  which  adopts  a  form  of  first-order  multiset  rewriting  to  describe  cryptographic  protocols 
and  developed  it  into  an  analysis  methodology.  This  idea  has  been  formalized  in  a  family  of  languages  generally  referred  to 
as  MSR.  This  report  is  about  MSR  2.0,  which  was  used  as  the  medium  of  a  multi-year  verification  effort  of  the  Kerberos  5 
authentication  protocol  SUES!!,  as  a  formal  language  where  to  investigate  foundational  notions  of  security  E),  and  as  an 
intermediate  formalism  to  relate  formalizations  in  other  languages  l30l[26l. 

In  MSR,  the  observation  that  protocol  transitions  may  be  naturally  expressed  as  a  form  of  rewriting  is  sharpened  to  a 
rigorous,  formal  definition  of  the  Dolev-Yao  model  by  means  of  multiset  rewriting  with  existential  quantification  [  27  46 1  • 
In  this  framework  protocol  execution  may  be  carried  out  symbolically.  Existential  quantification,  as  commonly  used  in 
formal  logic,  provides  a  natural  way  of  choosing  new  values,  such  as  new  keys  or  nonces.  Multiset  rewriting  provides  a  very 
precise  way  of  specifying  security  protocols  and  has  been  incorporated  into  various  high-level  specification  languages  for 
authentication  protocols,  for  example  CAPSL  (43l.  The  multiset  rewriting  formalism  allows  us  to  formulate  one  standard 
intruder  theory  that  describes  any  adversary  for  any  protocol. 

MSR  2.0  was  built  on  top  of  a  first  version  of  MSR,  which  we  will  call  MSR  1.0  and  that  was  largely  designed  at  Stanford 
University  in  1998-99.  MSR  1.0  consisted  of  an  elementary  fragment  of  first-order  multiset  rewriting  with  existential  quan¬ 
tifiers.  It  was  developed  to  study  foundational  questions  about  security  protocols,  whose  answers  were  unknown  back  then. 
The  first  such  result  was  that  establishing  whether  a  protocol  maintained  secrecy  is  undecidable  in  general  ||27|  [45]  [46] .  It  was 
then  used  to  investigates  specifications  written  in  other  protocol  specification  languages,  namely  strand  spaces  lf28l  l29l  i30ll 
and  process  algebra  (8i  171  [261 .  More  abstractly,  connections  with  linear  logic  were  also  made  |3H, 

The  main  purpose  of  this  report  is  to  act  as  a  centralized  and  largely  complete  references  to  MSR  2.0  in  the  context  of 
cryptographic  protocol  specification,  as  well  as  to  collect  results  and  proofs  that  were  never  published  before.  MSR  2.0  was 
developed  in  2000-02  at  the  Naval  Research  Laboratory  as  a  usable  language  to  write  actual  protocol  specifications  and 
verify  them.  It  was  extended  with  a  flexible  type  system  based  on  dependent  types  and  aspects  of  its  syntax  were  relaxed. 
This  was  mainly  a  response  to  the  fragility  of  MSR  1.0  as  a  language  for  specifying  concrete  protocols  |3Q|,  Bits  and  pieces 
of  MSR  2.0  have  been  presented  in  various  venues,  for  example  CEO  El  El-  A  formal  specification  of  this  language  in  a 
context  that  goes  beyond  security  protocols  can  be  found  in  (24).  This  slightly  more  general  language  has  been  implemented 
in  Maude  EH  Eg). 

MSR  2.0  was  meant  to  work  with  real-world  protocols.  Our  first  and  longest  case  study  involved  the  Kerberos  5  repeated 
authentication  protocol.  We  formalized  major  aspects  of  this  protocol  at  a  level  of  detail  that  had  not  been  attempted  before 
and  developed  an  accompanying  verification  methodology  to  analyze  it.  We  found  the  the  core  protocol  behaves  according 
to  its  specifications,  although  some  optional  components  displayed  innocuous  anomalies  mmmmm.  We  also  ex¬ 
amined  its  support  for  cross-realm  authentication,  a  rarely  used  feature,  and  found  that,  although  it  achieves  stated  security 
goals,  these  goals  are  so  weak  as  to  make  them  of  little  utility  in  practice  (32).  We  then  turned  our  attention  to  PKINIT, 
an  optional  subprotocol  of  Kerberos  based  on  public-key  exchanges.  Our  analysis  revealed  a  serious  vulnerability  in  its 
specification  |33}  34  35J  which  led  to  an  immediate  revision  of  the  Kerberos  5  standards.  We  also  relied  on  this  protocol 
in  J25]g)  where  we  used  MSR  2.0  to  support  security  analysis  in  the  computational  model  0.  Although  it  was  designed  for 
concrete  specifications,  MSR  2.0  proved  a  useful  formalism  where  to  carry  out  foundational  investigations  on  the  nature  of 
the  Dolev-Yao  intruder  |2l][T8)  and  also  to  explore  ideas  about  quantitative  notions  of  security  analysis  (23). 

More  recently,  we  have  designed  a  third  version  of  this  language,  MSR  3.0  (221 1361 1371,  which  has  much  deeper  roots 
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in  logic,  type  theory,  and  concurrency  theory.  Although  mostly  compatible  with  MSR  2.0,  it  simplifies  and  modularizes 
specifications,  and  also  bridges  the  traditional  divide  between  state-based  and  process-based  specifications  of  concurrent 
systems,  as  respectively  found  in  Petri  nets  and  process  algebra  for  example. 

This  report  is  organized  as  follows.  We  define  MSR’s  terms  and  messages  in  Section^]  its  state  constituents  and  their 
typing  infrastructure  in  Section [3]  and  rules  and  protocol  theories  in  Section [4]  Section [5]defines  the  notion  of  data  access 
specification  and  shows  that  it  is  decidable.  In  Section  [6]  we  present  the  execution  semantics  of  MSR  and  prove  that  it 
preserves  both  typing  and  data  access  specification  validity,  while  some  pragmatic  implementation  issues  are  discussed  in 
Section[7]  In  Section[8j  we  encode  the  standard  Dolev-Yao  intruder  in  our  language  and  prove  that  this  specification  captures 
any  other  attacker  we  may  define  in  MSR.  We  give  the  MSR  specification  of  three  examples  of  increasing  complexity  in 
Section[9]and  conclude  in  SectionITOl 


2  Typed  Messages 


In  Section  |2.1|  we  describe  the  messages,  or  more  generally  terms,  that  form  the  core  of  MSR.  Then  in  Section  2.2 


we 


introduce  the  typing  infrastructure  that  will  allow  us  to  make  sense  of  these  terms,  followed  by  the  typing  rules  that  defines 

We  proceed  in  Section  [2~4]  by  slightly  enlarging  the  definition  of  terms  and  types  to  admit 


their  validity  in  Section  2.3 


variables.  We  will  need  them  later  when  type-checking  protocol  rules.  We  conclude  in  Section |23]by  pointing  out  the  major 
differences  with  respect  to  the  messages  used  in  previous  work  on  MSR 


2.1  Messages 

Messages  are  obtained  by  applying  a  number  of  message  forming  constructs,  discussed  below,  to  a  variety  of  atomic  messages. 
The  atomic  messages  we  will  consider  in  this  report  are  principal  identifiers,  keys,  nonces,  and  raw  data  (i.e.  pieces  of  data 
that  have  no  other  function  in  a  protocol  than  to  be  transmitted).  We  formalize  our  notion  of  atomic  message  by  means  of  the 
following  grammatical  productions: 


Atomic  messages:  a  ::=  A  (Principal) 

|  k  (Key) 

n  (Nonce) 
m  (Raw  datum) 

Here  and  in  the  rest  of  this  document.  A,  k,  n,  and  m  will  range  over  principal  names,  keys,  nonces,  and  raw  data  respectively. 
We  will  sometimes  also  use  B  to  denote  a  principal.  Although  we  will  limit  the  discussion  in  this  report  to  these  kinds  of 
atomic  messages,  it  should  be  noted  that  others  can  be  accommodated  by  extending  the  appropriate  definitions. 

The  message  constructors  we  will  consider  consist  of  concatenation,  shared-key  encryption,  and  public-key  encryption. 
Altogether,  they  give  rise  to  the  following  definition  of  a  message,  or  more  properly  a  term. 

Messages:  t  ::=  a  (Atomic  messages) 
ft  f2  (Concatenation) 

{f}k  (Symmetric-key  encryption) 

{{/]}•  k  (Asymmetric-key  encryption) 

We  will  use  the  letter  t,  possibly  sub-  and/or  super-scripted,  to  range  over  terms.  Observe  that  we  use  a  different  syntax  (and 
later  typing  rules)  for  shared-key  and  public-key  encryption.  We  could  have  identified  them,  as  it  is  done  in  many  approaches. 
We  chose  instead  to  distinguish  them  to  show  the  flexibility  and  precision  of  our  technique. 

Again,  other  constructors,  for  example  digital  signatures  and  hash  functions,  can  easily  be  accommodated  by  extending 
the  appropriate  definitions.  We  refrain  from  doing  so  since  their  inclusion  would  lengthen  the  discussion  without  introducing 
substantially  new  concepts. 
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2.2  Types 

While  types  played  a  very  modest  role  in  the  original  definition  of  MSR  |27][30j,  they  stand  at  the  core  of  the  extension 
presented  in  this  report.  Through  typing,  we  will  not  only  enforce  basic  well-formedness  conditions  (e.g.  that  only  keys  be 
used  for  encrypting  a  message),  but  types  will  provide  a  statically  checkable  way  to  ascertain  complex  desiderata  such  as,  for 
example,  that  no  principal  may  grab  a  key  he/she  is  not  entitled  to  access.  The  central  role  of  types  in  our  present  approach  is 
witnessed  by  the  fact  that  they  subsume  and  integrally  replace  the  “persistent  information”  of  the  original  MSR  ll30ll. 

The  typing  machinery  that  best  fits  our  goals  is  based  on  the  type-theoretic  notion  of  dependent  product  types  with 
subsorting.  Rather  than  delving  into  the  depth  of  the  definitions  and  properties  of  this  formalism,  we  will  introduce  only  the 
facets  that  we  will  use,  and  only  to  the  extent  we  will  need  them.  In  particular,  we  will  not  conduct  an  in-depth  discussion 
of  this  type  theory;  we  will  even  stay  away  from  the  most  exotic  aspects  of  its  syntax.  Readers  who  wish  to  further  their 
understanding  of  this  formalism  are  invited  to  consult  gDEDBEl. 

Types  are  syntactic  constructions  that  are  used  to  classify  other  syntactic  expression,  such  as  terms.  By  doing  so,  they 
give  them  a  meaning,  saying  for  example  that  an  object  we  interpret  as  a  key  is  not  a  nonce.  Whenever  a  key  is  used  where  a 
nonce  is  expected,  something  has  gone  wrong  since  the  meaning  of  this  term  has  been  violated.  The  types  we  will  use  in  this 
document  are  summarized  in  the  following  grammar: 


principal 

(Principals) 

nonce 

(Nonces) 

shK  AH 

(Shared  keys) 

pubK  A 

(Public  keys) 

privK  k 

(Private  keys) 

msg 

(Messages) 

In  the  sequel,  r,  possibly  variously  decorated,  will  stand  for  a  type.  Needless  to  say,  the  types  “principal”  and  “nonce”  are 
used  to  classify  principals  and  nonces  respectively.  The  next  three  productions  allow  distinguishing  between  shared  keys, 
public  keys  and  private  keys.  Dependent  types  offer  a  simple  and  flexible  way  to  express  the  relations  that  hold  between  keys 
and  their  owner  or  other  keys.  Given  principals  “A”  and  “B”,  a  shared  key  “k”  between  “A”  and  “B”  will  have  type  “shK  AB”. 
Here,  the  type  of  the  key  depends  on  the  specific  principals  “A”  and  “B”.  Similarly,  a  constant  “k”  is  given  type  “pubK  A” 
to  indicate  that  it  is  a  public  key  belonging  to  “A”.  We  use  dependent  types  again  to  express  the  relation  between  a  public 
key  and  its  inverse.  Continuing  with  the  last  example,  the  inverse  of  “k”  will  have  type  “privK  k”,  from  which  it  is  easy  to 
establish  that  it  belongs  to  principal  “A”. 

We  will  use  the  type  msg  to  classify  generic  messages.  Clearly  raw  data  will  have  type  msg.  This  is  however  not  sufficient 
since  nonces,  keys,  and  principal  identifiers  are  routinely  part  of  messages.  We  solve  this  problem  by  imposing  a  subsorting 
relation  between  types.  We  formalize  this  relation  by  means  of  the  fol  lowing  judgment: 

t  ::  t'  t  is  a  subsort  ofr' 

In  this  report,  the  subsorting  relation  will  amount  to  having  each  of  the  types  discussed  above  with  the  exception  of  private 
keys  be  a  subtype  of  msg.  Its  extension  is  expressed  by  means  of  the  following  rules: 


- ss_pr 

principal  ::  msg 


- ss_nnc 

nonce  ::  msg 


-  ss_shK  -  ss_pbK 

shK  A  B  ::  msg  pubK  A  ::  msg 

These  rules  are  parametric  since,  for  example,  ss_shK  establishes  that  “shK  A  B  ::  msg”  holds  for  any  choice  of  the  principals 
“A”  and  “B”. 

Again,  the  types  and  the  subsorting  rules  above  should  be  thought  of  as  a  reasonable  instance  of  our  approach  rather 
than  the  approach  itself.  Other  schemas  can  be  specified  by  defining  appropriate  types  and  how  they  relate  to  each  other. 
For  example,  digital  signatures  could  be  accommodated  by  introducing  dedicated  dependent  types  akin  to  “pubK  A”  and 
“privK  k”.  In  another  scenario,  an  application  may  find  it  convenient  to  see  each  of  the  key-related  types  above  as  a  subtype 
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of  a  universal  key  type,  say  “key”,  in  turn  a  subsort  of  msg.  As  a  final  example,  we  may  want  to  define  distinct  types  for 
long-term  keys  and  have  them  not  be  a  subsort  of  msg,  prohibiting  in  this  way  the  transmission  of  long-term  secrets  as  parts 
of  messages;  more  complex  key  stratifications  could  be  captured  as  well. 

2.3  Typing 

In  the  first  part  of  this  section,  we  have  introduced  terms  and  the  types  intended  to  classify  them.  We  will  now  present  the 
typing  rules  that  will  allow  us  to  establish  whether  an  expression  built  according  to  the  syntax  of  terms  can  be  considered  a 
message  (more  in  general  whether  a  given  expression  has  a  certain  type). 

The  rules  below  systematically  reduce  the  typability  of  a  composite  term  to  the  validity  of  its  subterms.  This  is  adequate 
for  constructors,  but  atomic  messages  need  to  be  treated  specially  unless  we  are  willing  to  write  new  rules  for  them  each  time 
we  model  a  protocol.  Independence  of  rules  from  actual  atomic  messages  is  achieved  through  the  notion  of  a  signature.  A 
signature,  written  E,  is  a  finite  sequence  of  declarations  that  map  atomic  messages  to  their  type.  More  formally. 

Signatures:  E  ::=  •  (Empty  signature) 

E,  a  :  t  (Atomic  message  declaration) 

I  (...) 

The  dots  in  the  last  line  express  the  fact  that  this  definition  is  incomplete:  we  will  extend  it  in  the  next  section. 

We  assume  that  each  atomic  message  in  a  signature  is  declared  exactly  once.  We  will  also  often  elide  the  leading  from 
a  non-empty  signature,  and  promote  the  extension  operator  to  denote  signature  union.  This  operation  is  defined  only  if 
the  resulting  sequence  is  itself  a  signature  (in  particular  it  should  not  contain  multiple  declaration  for  the  same  constant). 

2.3.1  Typing  Messages 

Given  the  notions  introduced  so  far,  it  is  fairly  easy  to  define  a  meaningful  type  system  for  messages  and  the  other  types  we 
have  described.  In  order  to  accomplish  this  goal,  we  will  rely  on  the  following  message  typing  judgment: 

Eh  t  :  t  Term  t  has  type  r  in  signature  E 

All  composite  terms  have  type  msg,  given  that  their  constituent  submessages  are  correctly  typed.  This  implies  that  the 
subterms  of  a  concatenation  (t\  t2)  are  themselves  messages.  On  the  other  hand,  the  plaintext  part  t  of  an  encrypted  message 
{t,}k  should  have  type  msg  but  k  should  be  a  shared  key  between  two  principals.  Terms  encrypted  with  public  keys,  of  the 
form  {{ / are  handled  similarly.  This  intuition  is  formally  captured  in  the  following  typing  rules  for  messages: 

E  h  t\  :  msg  E  h  <2  :  rnsg 

-  mtp_cnc 

E  h  t\  t2  :  msg 

Eh  t  :  msg  E  h  fc  :  shK  A  f?  Eh  t  :  msg  Eh  k  :  pubK  A 

-  mtp_ske  -  mtp_pke 

E  h  {t}k  :  msg  E  h  :  msg 

These  rules  are  parametric,  as  witnessed  by  the  numerous  meta-variables  they  contain,  but  also  hypothetical  in  the  sense  that 
the  validity  of  the  consequent  relies  on  the  validity  of  their  premises. 

The  next  rule  reduces  verifying  that  a  term  t  has  type  r  to  checking  that  it  has  type  t'  for  some  subsort  of  r.  In  this  way, 
we  can  for  example  use  a  nonce  or  a  key  where  an  object  of  type  msg  is  expected.  The  formal  rule  is  as  follows: 

Eh  t  :  t'  t'  ::  t 

- mtp_ss 

E  h  t  :  t 

The  last  term  typing  rule  deals  with  elementary  messages  components.  An  atomic  message  a  has  a  type  r  if  the  signature 
at  hand  contains  the  declaration  “a  :  r”.  The  validity  of  the  type  r  in  E  is  independently  checked  by  verifying  the  validity  of 
a  signature. 

-  mtp_a 

(E,  a  :  t,  E')  h  a  :  r 


4 


2  TYPED  MESSAGES 


This  concludes  the  presentation  of  the  typing  rules  for  messages.  For  the  convenience  of  the  reader,  we  collect  all  the  rules 
presented  in  this  report  in  Appendix  |A| 

It  is  easy  to  see  that  the  well-typedness  of  a  message  is  a  decidable  property,  assuming  that  the  subsorting  relation  is 
acyclic  and  without  infinitely  descending  chains.  This  fact  is  captured  by  the  following  property. 

Property  2.1  Whenever  the  subsorting  relation  r  ::  t'  is  a  well-order,  it  is  decidable  whether  the  judgment  Eht:r  holds. 

Proof:  Observe  that  the  premises  of  all  rules  except  tp_ss  invoke  the  typing  judgment  on  subterms  of  the  message  appearing 
in  the  rule  conclusion,  if  at  all.  Since  signatures  are  finite,  the  unbound  meta-variables  in  the  premises  can  be  instantiated 
only  in  a  finite  number  of  ways.  Rule  mtp_ss  does  not  change  the  message,  but  checks  it  on  a  subtype.  Since  the  subsorting 
relation  is  a  well-order,  this  rule  can  be  applied  only  a  finite  number  of  times  before  breaking  up  the  message  using  another 
rule.  □ 


2.3.2  Validating  Types 

The  dependence  of  types  on  terms  can  make  a  syntactically  correct  type  meaningless.  For  example,  “privK  k”  is  not  valid  if 
k  has  type  “shK  A  II”.  We  check  the  validity  of  a  type  by  means  of  the  following  judgment. 

Eh  r  t  is  a  valid  type  in  signature  E 

Non-dependent  types  are  valid  in  every  signature: 

- ttp_pr  - ttp_nnc  - ttp_msg 

E  h  principal  E  h  nonce  E  h  msg 

However,  whenever  a  type  depends  on  a  term,  we  must  check  that  the  latter  is  well-formed  in  the  current  signature.  We  have 
the  following  rules: 

Eh  A:  principal  Eh  B  :  principal  E  h  A  :  principal  Eh  k  :  pubK  A 

- ttp_shK  - ttp_pbK  - ttp_pvK 

E  h  shK  AB  E  h  pubKA  E  h  privK  k 

Were  we  to  have  types  other  than  the  ones  considered  in  this  document,  we  would  need  to  extend  this  rule  set  with  additional 
rules  to  establish  their  validity. 

Since  we  have  shown  that  type-checking  terms  is  decidable,  this  property  extends  straightforwardly  to  types. 

Property  2.2  Whenever  the  subsorting  relation  t  ::  t'  is  a  well-order,  it  is  decidable  whether  the  judgment  E  h  r  holds. 

Proof:  The  rules  implementing  this  judgment  are  syntax-directed  with  respect  to  the  structure  of  types.  The  premises,  when 
present,  invoke  the  typing  judgment  that  we  know  is  decidable  given  the  assumptions  of  this  property.  □ 


2.3.3  Validating  Signatures 

Since  signatures  contain  declarations  that  attribute  a  type  to  an  atomic  message  (they  will  be  extended  in  Section[3]i,  we  must 
concern  ourselves  with  their  validity.  We  express  this  notion  by  means  of  the  judgment: 

h  E  E  is  a  valid  signatures 


The  rules  that  validate  this  judgment  are  given  below:  an  empty  signature  is  trivially  valid,  a  non-empty  signature  E,  a  :  r 
is  valid  if  the  type  of  its  last  declaration  is  valid  in  E,  and  the  tail  E  is  itself  a  valid  signature. 


E  h  r  h  E 

- itp_dot  - itp_a 

h  •  h  E, a  :  r 


(...) 


Since  we  will  extend  the  notion  of  signature,  we  will  need  to  provide  rules  validating  each  new  form  of  declaration.  This  is 
indicated  by  the  ellipsis  on  the  right. 

We  postpone  the  simple  decidability  statement  till  Section[3]where  we  will  complete  the  description  of  signatures. 
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2.4  Parametric  Messages 

Tuple  types  (see  Section  [3]i  and  protocol  rules  (see  Section  [4])  rely  on  objects  that  are  similar  to  messages  except  that  they 
may  contain  variables  to  be  instantiated  during  type-checking  and  execution,  respectively.  We  will  now  extend  the  definitions 
given  above  to  allow  for  this  possibility.  This  will  result  in  the  concepts  of  parametric  terms,  parametric  types,  and  typing 
rules  that  can  handle  them. 


2.4.1  Messages 


A  parametric  message  allows  variables  where  terms  could  appear  in  the  messages  of  Section  [2~T|  The  definition  is  updated  as 
follows: 


Parametric  messages:  t 


=  a 

(Atomic  messages) 

1  x 

( Variables ) 

tl  f 2 

( Concatenation ) 

1  {t}k 

(Symmetric-key  encryption ) 

1  M* 

( Asymmetric-key  encryption ) 

where  the  arrow  on  the  right  indicates  the  added  production. 

When  writing  judgments,  it  will  be  convenient  to  blur  the  distinction  between  atomic  constants  and  variables  since  they 
are  generally  treated  in  the  same  manner.  Indeed,  variables  can  been  seen  as  temporary  constants  whose  lifespan  is  limited 
to  a  type  fragment,  a  rule  or  a  role.  With  this  in  mind,  we  will  write  A  (or  B),  k,  and  n,  variously  decorated,  for  atomic 
constants  or  variables  that  are  principals,  keys,  and  nonces  respectively.  Whenever  the  object  we  want  to  refer  to  cannot  be 
but  a  constant  (mostly  in  the  execution  rules),  we  will  use  the  corresponding  serifed  letters:  A  (or  B),  k,  and  n.  Finally,  the 
letters  x,  y  and  z  will  stand  for  terms  that  must  be  variable. 

In  some  circumstances,  we  will  need  to  refer  to  objects  that  can  be  either  variables  or  atomic  message  constants,  but  not 
composite  terms.  We  call  these  terms  elementary  and  denote  them  with  the  letter  e,  variously  decorated. 

Since  most  of  the  object  we  will  be  dealing  with  in  the  rest  of  the  report  contain  variables,  we  will  use  the  wording  “term” 
(or  “message”)  to  refer  to  “parametric  terms”  (or  “messages”).  Whenever  we  will  be  working  with  terms  that  do  not  contain 
variables  (as  in  the  first  part  of  this  section),  we  will  talk  about  “ground”  terms  (or  messages),  unless  clear  from  the  context. 


2.4.2  Types  and  Contexts 


The  definition  of  types  does  not  change  except  that  the  embedded  terms  can  now  be  (possibly  contain)  variables.  Therefore, 


there  is  no  need  to  update  the  grammar  presented  in  Section  2.2 


We  reserve  the  name  signature  for  a  sequence  of  ground  declarations.  Whenever  variables  are  involved,  we  will  instead 
talk  about  typing  contexts.  A  typing  context,  denoted  T  is  a  signature  with  a  (finite)  number  of  variable  declarations  appended 
to  it: 

Typing  contexts:  T  ::=  S  (Plain  signature) 

T,x  :  t  (Extension  with  a  variable  declaration) 

I  (..J 


As  for  signatures,  we  will  later  extend  this  definition.  It  should  be  clear  that  the  type  r  of  a  declaration  x  :  t  in  a  typing 
context  can  itself  depend  on  variables.  Similarly  to  signatures,  we  require  that  variables  be  declared  exactly  once  in  a  context. 


2.4.3  Typing 

The  typing  rules  for  parametric  messages  change  little  with  respect  to  their  ground  counterparts:  the  main  difference  is  that, 
similarly  to  the  way  (ground)  atomic  terms  were  treated,  variables  need  to  be  validated  in  the  typing  context.  These  rules  are 
as  follows: 

T  h  t\  :  msg  T  h  f2  :  msg 

-  mtp/  _cnc 

r  I-  t\  f2  :  msg 
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T  F  t  :  msg  T  h  fc  :  shK4B  r  h  i:  msg  r  F  k  :  pubK  A 

-  mtp'  _ske  - mtp7  _pke 

r  h  {t}k  :  msg  r  F  :  msg 

T  F  t  :  t'  t'  ::  r 

-  mtp  _ss  -  mtp  _a  -  mtp  _x 

r  F  t  :  t  (E,  a  :  r,  T)  F  a  :  r  (r,  x  :  r,  T7)  F  x  :  r 


Once  we  interpret  variables  as  temporary  constants,  the  distinction  between  typing  contexts  and  signatures  vanishes,  and 
so  does  the  distinction  between  rules  mtp'_a  and  mtp'_x.  Indeed,  the  type  systems  for  ground  and  parametric  terms  become 
isomorphic.  We  will  observe  this  phenomenon  over  and  over.  Rather  than  duplicating  inference  rules  in  this  manner  (and 
doubling  the  size  of  this  report),  we  decided  to  sacrifice  in  precision  and  present  the  same  rules  for  typing  both  ground  and 
parametric  messages  (and  related  concepts).  Readers  bothered  by  this  approach  are  invited  to  fill  this  omission  by  themselves: 
it  is  a  matter  copying  each  rule  xxxjyyy  to  an  identical  rule  xxx'jyyy  and  replace  the  context  meta-variables  T  with  signature 
meta-variables  E,  or  vice  versa. 


We  apply  this  principle  right  away  to  the  rules  for  checking  the  validity  of  type.  We  simply  inherit  them  from  Section  2.3.2 


The  following  judgment  is  used  to  validate  a  typing  context: 


FT  f  ijfl  valid  typing  context 


The  rules  that  implement  it  are  given  below.  We  type-check  degenerate  contexts  by  means  of  the  similar  judgment  for 
signatures.  If  a  context  has  a  typing  declaration  x  :  r  for  a  variable  as  its  last  declaration,  we  validate  r  as  well  as  the  prefix 
T.  The  ellipsis  indicates  that  we  will  consider  additional  rules  to  validate  extensions  to  the  definition  of  context. 


F  E 

- ctp_sig 

F  E 


r  h  t  ft 

- ctp_x 

F  T,x  :  t 


(...) 


Given  our  interpretation  of  variables  as  temporary  constants,  it  is  clear  that  our  decidability  results  extend  to  the  parametric 
case.  We  abstain  from  repeating  them  here.  Direct  proofs  proceed  as  in  the  ground  cases. 


2.5  Changes 

We  will  now  compare  the  above  term  infrastructure  with  the  notion  of  message  used  in  earlier  versions  of  MSR  If27ll30l.  The 
main  differences  concern  the  types  and  the  way  they  are  used. 

1.  Structurally,  the  original  presentation  of  MSR  referred  to  so-called  simple  types,  i.e.  types  that  do  not  depend  on  terms. 
These  types  would  permit  distinguishing  objects  into  keys,  nonces,  messages,  etc.  (the  taxonomy  was  open-ended),  but 
would  not  allow  any  finer  classification  11301.  Subsorting  introduced  some  flexibility.  Most  of  the  information  that  is 
now  captured  through  dependencies  was  then  expressed  as  “persistent  predicates”  that  cluttered  protocol  specifications 
and  complicated  reasoning  about  them.  These  entities  have  been  dropped. 

2.  Typing  played  a  rather  inessential  role  in  l27l[30l:  constants  were  given  types,  but  rules  themselves  did  not  carry  such 
information.  Furthermore,  no  type  system  was  explicitly  presented  to  validate  terms  or  rules.  Typing  is  central  to 
the  language  proposed  in  this  report.  Every  object  is  typed  and  most  of  this  article  is  devoted  to  type-checking  and  its 
properties.  It  will  be  clear  as  the  discussion  develops  that  our  approach  allows  not  only  verifying  basic  well-formedness 
conditions  (e.g.  that  no  message  is  encrypted  with  a  nonce),  but  types  will  provide  a  statically  checkable  way  to  enforce 
complex  requirements  such  as,  for  example,  that  no  principal  uses  a  key  he/she  is  not  entitled  to  access. 

3.  In  this  document,  we  make  a  syntactic  distinction  between  shared-key  and  public-key  encryption.  Although  not  present 
in  127]  m,  we  could  have  easily  distinguished  the  two  forms  of  encryption  in  the  earlier  version  of  MSR. 


3  Message  Predicates  and  States 

States  are  a  fundamental  concept  in  MSR.  Indeed,  they  are  the  central  constituent  of  the  snapshots  of  a  protocol  execution. 
They  are  the  objects  transformed  by  rewrite  rules  to  simulate  message  exchange  and  information  update.  Finally,  together 
with  execution  traces,  they  are  the  hypothetical  scenarios  on  which  protocol  analysis  is  based. 
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In  this  section,  we  will  formalize  the  concept  of  state  in  MSR,  together  with  the  constructions  needed  to  implement  it.  In 
Section  3.1  we  introduce  message  tuples  and  typing  rules  for  them.  Then  in  Section  3.2  we  discuss  the  message  predicates 
that  appear  in  a  state,  and  in  Section  3.3  we  define  states.  We  conclude  in  Section  3.4  with  the  introduction  of  parametric 
variants  of  these  various  concepts. 


3.1  Message  Tuples  and  Dependent  Types 


As  we  will  see  shortly,  message  predicates  are  atomic  first-order  formulas  with  zero  or  more  terms  as  their  arguments.  In  this 
section,  we  are  concerned  with  formalizing  the  concept  of  tuple  and  presenting  suitable  typing  rules  for  them.  We  introduced 
term  tuples  in  Section  3.1.1  and  present  the  corresponding  notion  of  dependent  tuple  types  in  Section  3.1.2  We  define  the 


notion  of  term  substitution  in  Section  3.1.3  and  use  it  in  the  typing  rules  for  tuples  in  Section  3.1.4 


3.1.1  Message  Tuples 

A  message  tuple  is  an  ordered  sequence  of  terms.  It  is  trivially  defined  as  follows: 

Message  tuples  t  ::=  •  (Empty  tuple) 

t ,  t  (Tuple  extension) 

We  will  often  omit  the  leading  •  whenever  a  tuple  is  not  empty. 


3.1.2  Dependent  Tuple  Types 

It  is  tempting  to  define  the  type  of  a  tuple  as  the  sequence  of  the  types  of  its  components.  Therefore,  if  A  is  a  principal  name 
and  kA  is  a  public  key  for  A,  the  tuple  (A,  kA)  would  have  type  “principal  x  pubK  A”  (the  Cartesian  product  symbol  “x”  is 
the  standard  constructor  for  tuple  types).  This  construction  allows  us  to  associate  a  generic  principal  with  A’s  public  key:  if 
B  is  another  principal,  then  (B,  kA)  will  have  this  type  as  well.  We  will  often  need  stricter  associations,  such  as  between  a 
principal  and  its  own  public  key.  In  order  to  achieve  this,  we  will  rely  on  the  notion  of  dependent  tuple  type.  In  this  example, 
the  tuple  (A,  kA)  will  be  attributed  type  “principal1-4-1 * *  x  pubK  A”,  where  the  variable  A  in  “principal*-"4-*’’  records  the  name 
of  the  principal  at  hands  and  forces  the  type  of  the  key  to  be  “pubK  A”  for  this  particular  A:  therefore  (A,  kA)  is  valid,  but 
(B,  kA)  is  now  ill-typed  since  kA  has  type  “pubK  A”  rather  than  the  expected  “pubK  B”[^| 

We  do  attribute  a  type  to  a  term  tuple  by  collecting  the  type  of  each  constituent  message,  but  we  label  these  objects  with 
variables  to  be  used  in  later  types  that  may  depend  on  them.  A  dependent  tuple  type  is  therefore  an  ordered  sequence  of  types 
parametrized  as  follows: 

Tuple  types  t  ::=  •  (Empty  tuple) 

r(x)  x  t  (Tuple  type  extension) 

In  the  second  line  of  this  definition,  the  notation  i'x>  on  the  left  of  the  Cartesian  product  symbol  binds  the  variable  x  in  the 
tuple  type  t  to  its  right.  Similarly  for  example  to  a  quantifier,  is  a  binder.  Variables  that  are  not  bound  in  this  way  are 
said  to  be  free.  We  will  often  be  interested  in  closed  tuple  types,  all  of  whose  variables  are  bound.  The  scope  of  a  binder  is 
the  expression  over  which  its  binding  action  spans.  The  scope  of  our  binders  extends  to  the  entire  tuple  type  to  its  right. 

Given  a  dependent  tuple  type  x  r,  we  will  drop  the  label  <x>  whenever  the  variable  x  does  not  occur  (free)  in  t.  The 
resulting  simplified  notation,  r  x  r ,  will  help  writing  more  legible  specifications  when  possible.  As  for  term  tuples,  we  will 
omit  the  leading  whenever  convenient. 


3.1.3  Substitutions 

In  the  example  above,  verifying  that  the  tuple  (A,  kA)  has  type  “principal*-4*  x  pubK  A”  proceeds  as  follows:  we  first  check 
that  A  is  indeed  a  principal,  but  before  continuing  with  the  validation  of  the  right  component  of  this  tuple,  we  must  replace 

1  Our  dependent  tuple  types  are  usually  called  weak  dependent  sums  in  the  type  theoretic  community,  and  the  standard  notation  for  the  dependent  tuple 

type  we  have  written  as  "principal*  71)  x  pubK  A”  is  “T,A  :  principal.  pubK  A".  We  believe  that  our  syntax  is  likely  to  be  more  clear  to  the  target  audience 

of  this  document. 
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every  occurrence  of  the  variable  A  with  the  principal  name  A.  Therefore,  type-checking  a  tuple  type  in  general  relies  on  the 
operation  of  substitution  of  a  term  t  for  a  variable  x  in  a  tuple  type  r,  denoted  [t/x}f.  Since  tuple  types  are  built  on  types, 
which  in  turn  can  contain  terms,  we  shall  define  two  more  substitution  operations:  the  replacement  of  t  for  x  in  a  type  r  and  a 
term  t',  denoted  [t/ x]t  and  [t/x]t'  respectively.  For  simplicity,  we  overload  the  bracket  notation  to  denote  the  application  of 
the  substitution  operation  to  objects  belonging  to  different  syntactic  categories.  These  operations  are  defined  in  the  following 
table: 


[t/x\f 

[t/x\r 

[t/x\t' 

[t/x\- 

[t/x\(r^  x  r)  =  {[t / xlr)^  x  ([t/x]r) 

[t/x]  principal  =  principal 

[f/a;]nonce  =  nonce 

[f/a;]shK  A  B  =  shK  {\t/x\A)  {[t/x\B) 

[f/a;]pubKA  =  pubK  (\t/x\A) 

[f/a;]privK  k  =  privK  ([t/x]k) 

[i/a;]msg  =  msg 

[t/x\a  =  a 

[t/x\y  =  lfy  =  x 

L  '  J  \y  otherwise 

[t/x\{t'1t'2)=  ([t/x]^)  {[t/x]t'2) 
[t/x\{t'}k  =  {[t/x]t'  }[t/x]k 
[t/x\lt'}k  =  l\t/x]t'} }[t/x]k 

In  the  second  line  of  the  leftmost  column,  we  implicitly  assume  that  the  bound  variable  y  is  different  from  x  and  from  any 
variable  possibly  contained  in  t  (this  would  result  in  a  variable  capture :  a  free  variable  in  t  would  become  bound  once  the 
substitution  has  been  completed).  We  take  care  of  these  situations  by  implicitly  renaming  the  bound  variable  ( y  in  this  case) 
to  a  variable  name  (z  say)  that  does  not  appear  in  t  or  t.  This  is  known  as  a-conversion  in  type-theoretic  circles.  Intuitively,  if 
we  think  of  variables  as  place  holders,  binders  dictate  which  place  holders  must  be  instantiated  with  the  same  term.  Variable 
names  implement  this  association.  Besides  a  possibly  mnemonic  function,  the  names  of  variables  themselves  have  little 
importance  and  can  be  replaced  with  arbitrary  strings  as  long  as  no  conflict  with  other  variables  is  introduced. 

3.1.4  Typing 

Type-checking  a  message  tuple  with  respect  to  a  dependent  tuple  type  reduces  to  verifying  that  each  component  message  has 
the  type  in  the  corresponding  position.  This  is  formalized  by  the  following  judgment: 

E  h  (:f  Term  tuple  t  has  type  t  in  signature  £ 

The  rules  implementing  the  typing  judgment  for  tuples  are  given  below:  the  type  of  empty  message  tuple  is  the  empty  tuple 
type,  otherwise,  components  must  match  after  performing  the  appropriate  substitutions  to  satisfy  possible  dependencies. 

E  h  t  :  t  E  h  i:  \t/x]r 

-  mtp.dot  -  mtp_ext 

Eh'-  Eh  (t,t)  :  x  f 

Observe  that  all  the  judgments  in  these  rules  mention  a  signature  rather  than  a  typing  context.  In  particular,  the  variable  x 
exposed  in  the  rightmost  premise  of  rule  mtp  ext  is  immediately  substituted  with  the  term  t,  which  is  proved  ground  in  the 
left  premise  of  this  rule. 

These  rules  implement  a  decision  procedure  for  the  tuple  typing  judgment,  as  expressed  by  the  following  property: 

Property  3.1  Whenever  the  subsorting  relation  t  ::  t'  is  a  well-order,  it  is  decidable  whether  the  judgment  £  h  t  :  r  holds. 

Proof:  The  substitution  operations  introduced  in  the  previous  section  are  computable  since  their  definition  visits  each  subex¬ 
pression  in  the  tuple  type,  type  or  term  being  instantiated  exactly  once  (and  these  objects  are  finite).  The  validity  of  a  (finite) 
term  tuple  is  then  decidable  based  on  the  analogous  property  for  types.  □ 


We  now  extend  the  notion  of  validity  of  a  type  to  tuples  of  types.  We  rely  on  the  following  judgment  to  expresses  this 
relation: 


r  h  r 


t  is  a  valid  tuple  type  in  typing  context  T 
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The  corresponding  typing  rules  simply  check  that  every  component  of  a  tuple  type  is  a  valid  type.  Possible  dependencies 
of  later  types  on  earlier  components  are  resolved  by  assuming  that  the  binding  variable  has  the  given  type.  Observe  that, 
consequently,  this  typing  judgment  is  assessed  relative  to  a  typing  context  rather  than  a  signature. 

Thr  T,x:rl-r 

- ttp_dot  -  ttp_ext 

r  h  •  r  h  r{x)  x  t 

In  rule  ftp  ext,  we  rely  on  implicit  o-conversion  to  rename  the  bound  variable  in  case  another  declaration  for  it  already 
occurs  in  T. 


3.2  Message  Predicates 

The  predicates  that  can  enter  a  state  or  a  rewrite  rule  are  of  three  kinds: 

•  First,  the  predicate  N(  )  implements  the  contents  of  the  public  network  in  a  distributed  fashion:  for  each  (ground) 
message  t  currently  in  transit,  the  state  will  contain  a  component  of  the  form  l\l(t). 

•  Second,  active  roles  rely  on  a  number  of  role  state  predicates ,  one  for  each  rule  in  them,  of  the  form  L;  (_,... ,  _), 
where  l  is  a  unique  identifying  label.  The  arguments  of  this  predicate  record  the  value  of  the  known  parameters  of  the 
execution  of  the  role  up  to  the  current  point. 

•  Third,  a  principal  A  can  store  data  in  private  memory  predicates  of  the  form  M  4  (_, ...,_)  that  survives  role  termination 
and  can  be  used  across  the  execution  of  different  roles,  as  long  as  the  principal  stays  the  same. 

The  reader  familiar  with  our  previous  work  on  MSR  will  have  noticed  a  number  of  differences  with  respect  to  the  definitions 
given  in  EH®-  Memory  predicates  are  indeed  new.  They  are  intended  to  model  situations  that  need  to  maintain  data  private 
across  role  executions:  for  example,  this  allows  a  principal  to  remember  its  Kerberos  ticket,  or  the  trusted-third-party  of  a  fair 
exchange  protocol  to  avoid  fraudulent  recoveries  from  aborted  transactions.  Another  difference  with  respect  to  earlier  work 
is  the  absence  of  a  dedicated  predicate  retaining  the  intruder’s  knowledge.  This  can  however  be  easily  implemented  using 
memory  predicates. 

Every  protocol  relies  on  a  public  network.  Therefore,  we  will  hardwire  the  network  predicate  N  (_)  in  our  language.  Local 
state  and  memory  predicates  are  different:  they  are  defined  on  a  per-protocol  basis.  This  is  similar  to  principals  and  keys.  We 
therefore  maintain  generality  by  declaring  them  as  part  of  the  signature.  We  can  now  complete  the  definition  of  a  signature 


as  lunuws. 

Signatures  E  ::= 

(Empty  signature) 

|  E,  a  :  r 

(Atomic  message  declaration ) 

1  S,  L r.r 

( Local  state  predicate  declaration) 

1  E,  M_  :  t 

(Memory  predicate  declaration ) 

Given  this  extension  to  signatures,  we  can  define  typing  rules  to  validate  message  predicates.  This  relation  is  captured  by 
the  following  judgment: 


Eh  P 


P  is  a  valid  message  predicate  in  signature  E 


The  rules  implementing  this  judgment  are  given  below.  The  argument  of  a  network  predicate  must  be  a  valid  message.  The 
type  of  the  arguments  of  role  state  and  memory  predicates  must  correspond  to  the  declared  type  for  this  predicate.  We  regard 
the  subscript  A  in  a  memory  predicate  M^(t)  as  if  it  were  the  first  argument  for  typing  purposes. 


E  h  t  :  msg 

- ptp_net 

E  h  N(t) 


(S,  L/  :  t,  E')  h  t  :  r 

- ptp_rsp 

(E,  \-i  :  t,  E')  h  Li(t) 


(E,  M_  :  r,  E')  h  (. A,t )  :  f 

- ptp_mem 

(E,  M  :  r,  E7)  h  MA(i) 
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We  now  extend  the  rules  that  validate  signatures  to  take  role  state  and  memory  predicate  declarations  into  consideration. 
We  require  that  the  first  argument  of  a  role  state  and  memory  predicate  be  a  principal,  this  will  be  the  owner  of  the  role. 

E  h  principal*-"4'*  x  t  h  E  Eh  principal*-"4)  x  r  h  E 

^  J  - itp_rsp  - itp_mem 

h  E,  L;  :  principal*"4-*  x  t  h  E,  M_  :  principal*"4-*  x  t 

The  dots  on  the  left  of  these  rules  represent  the  rules  for  signature  validation  given  in  Section  [2. 3. 3|  A  complete  set  of  rules 
is  given  in  Appendix  |A| 

We  postpone  discussing  the  decidability  of  type-checking  message  predicates  till  states  are  introduced.  However,  we  are 
now  in  a  position  to  verify  the  decidability  of  the  signature  validation  judgment.  We  have  the  following  property: 

Property  3.2  Whenever  the  subsorting  relation  r  ::  t'  is  a  well-order,  it  is  decidable  whether  the  judgment  h  E  holds. 


Proof:  Since  signatures  are  finite,  this  result  reduces  to  the  decidability  of  validating  types  and  tuple  types,  which  we  have 
proved  in  Sections  2.3.2  and  3.1.4  □ 


3.3  States 


A  state  is  a  finite  collection  of  ground  state  predicates.  The  syntax  of  states  is  formalized  by  means  of  the  following  grammar: 


States:  S 


(Empty  state) 

S.  N(t)  (Extension  with  a  network  predicate) 
S.  L/(t )  (Extension  with  a  role  state  predicate) 
S,  MA(t)  (Extension  with  a  memory  predicate) 


As  for  signatures  and  contexts,  we  will  omit  the  leading  and  interpret  the  extension  construct  as  a  union  operator.  It 
will  be  convenient  to  abstract  from  the  order  of  the  component  predicates  of  a  state,  treating  them  as  if  they  formed  a  multiset. 

The  validity  of  a  state  reduces  to  checking  that  each  component  predicate  is  well-formed  in  the  current  signature.  We 
formalize  this  by  means  of  the  judgment 


E  h  S  S  is  a  valid  state  in  signature  E 


which  is  implemented  by  the  following  two  rules: 


E 


- stp_dot 

h  • 


Eh  S  E  h  P 

- stp_ext 

E  h  (S,P) 


We  conclude  the  presentation  of  states  by  showing  that  validating  these  objects  is  decidable. 


Property  3.3  Whenever  the  subsorting  relation  r  ::  t'  is  a  well-order,  it  is  decidable  whether  the  judgment  E  h  S  holds. 

Proof:  The  decidability  result  for  term  tuples  allows  an  easy  proof  of  the  analogous  property  for  each  of  our  message 
predicates.  Since  states  are  finite  sequences  of  such  predicates,  it  is  decidable  whether  a  state  is  valid.  □ 


3.4  Parametric  Message  Predicates 

Protocol  rules  transform  states.  They  do  so  by  identifying  a  number  of  component  predicates,  removing  them  from  the  state, 
and  adding  other,  usually  related,  state  elements.  The  antecedent  and  consequent  of  a  rewrite  rule  embed  therefore  substates. 
However,  in  order  to  be  applicable  to  a  wide  array  of  states,  rules  usually  contain  variables  that  are  instantiated  at  application 
time.  This  calls  for  a  parametric  notion  of  states  and  message  predicates. 
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For  the  most  part,  this  reduces  to  admitting  variables  in  embedded  terms.  However,  role  state  predicates  need  to  be  created 
on  the  spot  in  order  to  avoid  interferences.  We  achieve  this  by  introducing  variables,  denoted  L,  that  are  instantiated  to  actual 
role  state  predicates  during  application.  This  makes  our  language  weakly  second-order,  although  we  could  easily  reduce  it 
to  the  first  order  by  interpreting  a  role  state  predicate  L/  as  the  symbol  L  indexed  by  a  label  l  that  is  kept  as  a  variable  in 
rules.  We  however  opt  for  the  more  direct  solution.  With  this  insight,  we  can  now  present  the  complete  definition  of  a  typing 
context. 

Typing  context  T  ::=  S  (Plain  signature) 

T,  x  :  r  (Extension  with  a  variable  declaration ) 

T,  L  :  t  (Extension  with  a  role  state  predicate  declaration) 

The  typing  rule  for  role  state  predicate  variables  is  constructed  as  for  their  non-parametric  counterpart  in  signatures.  Conse¬ 
quently,  the  typing  rules  for  contexts  are  completed  as  follows: 

T  h  principal*  4-1  x  t  Is  T 

^  j  - ctp_rsp 

F  T,  L  :  principal*'45  x  t 


3.5  Changes 

In  this  final  part  of  the  current  section,  we  will  analyze  the  main  differences  between  the  notion  of  state  and  related  concepts 
defined  above  and  the  analogous  entities  from  the  original  definition  of  MSR  t27l[30l. 

Typing  constitutes  a  minor  distinction  at  this  level  since  both  versions  of  MSR  rely  on  typed  predicate  names,  although 
little  use  of  this  aspect  was  made  in  |27j  30j| .  Our  present  use  of  dependent  tuple  types  is  mostly  a  consequence  of  our 
adoption  of  dependent  types  to  classify  terms.  The  major  differences  regard  instead  the  introduction  of  memory  predicates 
and  the  elimination  of  persistent  information  and  distinguished  intruder  knowledge  predicates  in  states. 

1.  In  earlier  versions  of  MSR,  a  principal  had  no  way  to  remember  data  across  role  executions:  role  state  predicates  are  lo¬ 
cal  to  a  role  instance,  and  network  messages  are  not  intended  for  storing  private  information.  Memory  predicates  survive 
role  termination.  As  already  mentioned,  this  is  useful  when  modeling  scenarios  that  require  remembering  information 
across  role  executions:  for  example,  this  allows  a  principal  to  remember  its  Kerberos  ticket,  or  the  trusted-third-party 
of  a  fair  exchange  protocol  to  avoid  fraudulent  recoveries  from  aborted  transactions.  Another  novel  important  use  of 
memory  predicate  is  in  modeling  protocols  consisting  of  a  number  of  subprotocols:  these  predicates  allow  subprotocols 
to  call  each  other  and  share  data. 

2.  There  is  no  trace  in  the  above  definitions  of  the  persistent  information  that  formed  the  immutable  portion  of  the  state 
of  MSR  in  112711301.  The  functionality  of  those  predicates  is  now  performed  by  the  strong  typing  policy  of  our  updated 
framework,  and  in  particular  by  our  reliance  on  dependent  types. 

3.  Finally,  we  should  point  out  the  absence  of  a  dedicated  predicate  intended  to  hold  the  intruder’s  knowledge.  This  aspect 
of  our  earlier  work  can  now  be  realized  transparently  through  memory  predicates. 


4  Multiset  Rewriting  Theories 

In  the  past,  cryptoprotocols  have  often  been  presented  as  the  temporal  sequence  of  messages  being  transmitted  during  a 
“normal”  run.  Recent  proposals  champion  a  view  that  places  the  involved  parties  in  the  foreground.  A  protocol  is  then  a 
collection  of  independent  roles  that  communicate  by  exchanging  messages,  without  any  reference  to  runs  of  any  kind.  A  role 
has  an  owner,  the  principal  that  executes  it,  and  specifies  the  sequence  of  messages  that  he/she  will  send,  possibly  in  response 
to  receiving  messages  of  some  expected  form.  A  role  can  therefore  be  seen  as  a  reactive  system. 

MSR  adopts  and  formalizes  this  perspective.  It  represents  protocols  as  a  set  of  syntactic  entities  that  we  also  call  roles.  A 
role  is  itself  given  as  a  parameterized  collection  of  multiset  rewrite  rules  that  encode  the  expected  message  receptions  and  the 
corresponding  transmission.  Rule  firing  emulates  receiving  (and  accepting)  a  message  and/or  sending  a  message,  the  smallest 
execution  steps. 
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This  section  defines  rules,  roles  and  protocol  theories,  and  provides  typing  rules  for  them.  More  specifically,  in  Sec¬ 
tion  14.11  we  introduce  rules  and  their  constituents.  Roles  are  defined  in  Section  14.21  Then,  in  Section  14.31  we  turn  our 


attention  to  protocol  theories.  Finally,  in  Section  4.4  we  anticipate  the  dynamic  notion  of  an  active  role  and  present  typing 
rules  for  these  entities.  Protocol  theories  and  roles  will  be  further  discussed  in  Sections  [5] and  [6] which  respectively  focus  on 
data  access  specification  as  an  additional  syntactic  check  and  on  execution.  Section  [reexamines  how  these  definitions  differ 
from  our  original  presentation  of  MSR. 


4.1  Rules 


With  a  slight  imprecision  that  will  be  corrected  as  the  discussion  proceeds,  a  rule  has  the  form  “Ihs  —>  rhs”.  Rules  are  the 
basic  mechanism  that  enables  the  transformation  of  a  state  into  another,  and  therefore  the  simulation  of  protocol  execution: 
whenever  the  antecedent  “Ihs”  matches  part  of  the  current  state,  this  portion  may  be  substituted  with  the  consequent  “rhs” 
(after  some  processing). 

It  is  convenient  to  make  protocol  rules  parametric  so  that  the  same  rule  can  be  used  in  a  number  of  slightly  different 
scenarios  (e.g.  without  fixing  interlocutors  or  nonces).  A  typical  rule  will  therefore  mention  variables  x%, . . . ,  xn  that  will 
be  instantiated  to  actual  terms  during  execution.  Typed  universal  quantifiers  can  conveniently  express  this  fact  so  that  rules 
assume  the  form  “Mx\  :  T\.  ...  Mxn  :  rn.  (Ihs  — »  rhs)”.  This  idea  is  more  precisely  captured  by  the  following  grammar: 

Rule:  r  ::=  Uis  —¥  rhs  (Rule  core) 

\/x:r.r  (Parameter  closure) 


The  universal  quantifiers  used  in  rules  bind  the  variables  they  are  applied  to.  Variables  that  are  not  bound  by  any  quantifier 
are  said  to  be  free.  Free  variables  can  occur  in  the  construction  of  a  rule,  but  roles  themselves  should  have  all  their  variables 
bound  (this  is  enforced  by  the  typing  rules):  they  are  said  to  be  closed.  The  scope  of  a  binder  is  the  expression  over  which  its 
binding  action  spans.  The  scope  of  all  the  binders  in  the  above  productions  spans  over  a  whole  rule. 

The  left-hand  side ,  or  antecedent ,  of  a  rule  is  a  finite  collection  of  parametric  message  predicates,  and  is  therefore  given 
by  the  following  grammar  for  predicate  sequences: 


Predicate  sequences:  Ihs 


Ihs ,  N(f) 
Ihs ,  L(E) 
Ihs ,  MA(t) 


(Empty  predicate  sequence) 
(Extension  with  a  network  predicate) 
(Extension  with  a  role  state  predicate ) 
(Extension  with  a  memory  predicate) 


Observe  that  rule  antecedents  and  in  general  predicate  sequences  differ  from  states  (see  Section [T3|  mainly  by  the  limited 
instantiation  of  role  state  predicates:  in  a  rule,  these  objects  consist  of  a  role  state  predicate  variable  applied  to  as  many 
elementary  terms  as  dictated  by  its  type  (as  enforced  by  the  typing  rules  below).  Recall  that  elementary  terms  are  either 
variables  or  atomic  message  constants.  Network  and  memory  predicates  will  in  general  contain  parametric  terms,  although 
not  necessarily  raw  variables  as  arguments.  It  will  be  convenient  to  treat  predicate  sequences  as  multisets. 

The  right-hand  side,  or  consequent,  of  a  rule  consists  of  a  predicate  sequence  possibly  prefixed  by  a  finite  string  of 
fresh  data  declarations  such  as  nonces  or  short-term  keys.  We  rely  on  the  existential  quantification  symbol  to  express  data 
generation.  We  have  the  following  grammar: 


Right-Eland  sides:  rhs  ::=  Ihs  (Sequence  of  message  predicates) 

3x  :  r.  rhs  (Fresh  data  generation ) 


The  notion  of  fresh  and  bound  variable  discussed  earlier  applies  also  here.  Again,  right-hand  sides  are  considered  equal  up 
to  a- conversion  of  their  bound  variables.  Notice  that  the  scope  of  these  quantifiers  is  limited  to  the  right-hand  side  of  the 
current  rule.  Later  rules  can  refer  to  the  values  created  by  these  variables  by  introducing  universal  quantifiers  of  the  proper 
type:  synchronization  is  ensured  by  their  occurrence  in  the  role  state  predicates. 

We  can  now  present  the  typing  rules  for  rules  and  their  components.  We  shall  first  turn  our  attention  to  rule  consequents, 
to  which  we  attribute  the  following  typing  judgment  (the  superscript  “r”  is  intended  to  distinguish  this  judgment  from  the 
analogous  relation  for  states): 


r  F  rhs 


rhs  is  a  valid  rule  consequent  in  typing  context  T 
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Since  right-hand  sides  are  usually  deeply  embedded  in  rules,  their  validity  must  in  general  be  checked  relative  to  a  typing 
context  rather  than  a  simple  signature.  This  context  will  include  the  declaration  of  all  the  previously  introduced  variables.  We 
have  the  following  typing  rules: 


T  h  r  (T,  x  :  t)  F  rhs 

- rtp_nnc 

T  F  3  x:r.  rhs 


T  F  Ihs 

- rtp_seq 

T  F  Ihs 


Rule  rtp_nnc  validates  consequents  that  start  with  a  fresh  datum  declaration.  The  left  premise  verifies  that  the  type  r  of  the 
variable  x  is  valid.  This  is  necessary  since  otherwise  invalid  types  may  not  be  caught.  The  right  premise  extends  the  current 
typing  context  with  the  declaration  for  x  and  attempts  to  validate  the  rest  of  the  consequent.  The  addition  of  x  :  r  to  the 
context  will  allow  using  rule  mtp  a  (see  Section  2.3.1 1  to  check  every  occurrence  of  x  in  p.  We  required  that  no  variable 
in  a  typing  context  or  signature  be  declared  more  than  once.  Implicit  a-conversion  provides  a  simple  way  to  implement  this 
constraint:  if  a  variable  named  x  is  already  contained  in  T,  we  implicitly  choose  an  unused  symbol,  use  it  to  rename  every 
occurrence  of  x  in  3a;  :  r.  rhs,  and  seamlessly  apply  rule  rtp_nnc  to  this  expression. 


Once  all  existential  quantifiers  have  been  stripped  from  a  rule  consequent,  rule  rtp_seq  invokes  the  typing  judgment  for 
(parametric)  states  to  validate  the  exposed  predicate  sequence.  This  is  sufficient  since,  as  we  observed,  a  predicate  sequence 
is  a  parametric  state  of  a  particular  form. 

Given  the  above  typing  rules,  the  following  judgment  validates  rules  themselves: 


T  F  r 


r  is  a  valid  rule  in  typing  context  T 


It  is  implemented  by  the  following  two  rules: 

T  F  Ihs  T  F  rhs  E  F  r  (T,  x  :  r)  F  p 

- utp_core  - utp_all 

T  F  Ihs  — »  rhs  T  F  Va;  :  r.  p 

Rule  utp_core  reduces  rule  validation  to  type-checking  its  antecedent  as  a  parametric  state  and  verifying  its  right-hand  side  as 
described  above.  The  quantifier  in  rule  utp_all  is  treated  as  in  the  case  of  rtp_nnc  and  should  not  require  further  discussion. 
At  this  point,  we  can  show  that  it  can  be  decided  whether  a  rule  is  well  typed.  We  have  the  following  proposition: 


Property  4.1  Whenever  the  subsorting  relation  r  ::  t'  is  a  well-order,  it  is  decidable  whether  the  judgment  Y  F  r  holds. 


Proof:  Type-checking  a  rule  reduces  to  the  validation  of  parametric  states  and  types  after  a  finite  number  of  application  of 
the  typing  rules  seen  in  this  section.  Since  the  analogous  judgments  for  states  and  types  are  decidable  and  the  choice  of  which 
rule  to  apply  is  syntax-directed,  type-checking  is  decidable  for  rules  as  well.  □ 


4.2  Roles 

Role  state  predicates  record  the  information  accessed  by  a  rule.  They  are  also  the  mechanism  by  which  a  rule  can  enable  the 
execution  of  another  rule  in  the  same  role.  Relying  on  a  fixed  protocol-wide  set  of  role  state  predicates  is  dangerous  since  it 
could  cause  unexpected  interferences  between  different  instances  of  a  role  executing  at  the  same  time.  Instead,  we  make  role 
state  predicates  local  to  a  role  by  requiring  that  fresh  names  be  used  each  time  a  new  instance  of  a  role  is  executed.  As  in  the 
case  of  rule  consequents,  we  achieve  this  effect  by  using  existential  quantifiers:  we  prefix  a  collection  of  rules  p  that  should 
share  the  same  role  state  predicate  L  by  a  declaration  of  the  form  “3 L  :  r”,  where  the  typed  existential  quantifier  expresses 
the  fact  that  L  should  be  instantiated  with  a  fresh  role  state  predicate  name  of  type  r. 

With  this  insight,  the  following  grammar  defines  the  notion  of  rule  collection: 

Rule  collections:  p  ::=  •  (Empty  role) 

3 L  :  t.  p  (Role  state  predicate  parameter  declaration) 
r,  p  (Extension  with  a  rule) 
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It  should  be  observed  that  this  definition  allows  for  role  state  predicate  parameters  declarations  and  rules  to  be  interleaved  in 
a  rule  collection.  However  we  generally  divide  a  collection  in  a  preamble  where  all  roles  state  parameters  are  declared,  and  a 
body  that  lists  the  rules  that  constitute  a  role. 

The  following  judgment  has  the  function  to  validate  a  rule  collection: 

T  h  p  p  is  a  valid  rule  collection  in  typing  context  T 

The  following  three  rules  that  realize  it: 


TI-r(r,L:r)l-p  T  h  r  T  h  p 

- otp_dot  - otp_rsp  - otp_rule 

T  h  •  T  h  3L  :  t.  p  T  h  r,  p 

The  quantifier  in  rule  otp_rsp  is  treated  as  in  the  case  of  rtp_nnc:  the  left  premise  validates  the  tuple  type  t  in  the  current 
context  T,  while  the  other  premise  analyzes  p  after  introducing  the  role  state  predicate  parameter  L  in  T.  The  techniques  for 
handling  bound  variables  we  just  discussed  apply  also  here.  Rule  otp  rule  applies  when  a  rule  collection  starts  with  a  rule  r. 

A  role  is  given  as  the  association  between  a  role  owner  A  and  a  collection  of  rules  p.  Some  roles,  such  as  those  imple¬ 
menting  a  server  or  an  intruder,  are  intrinsically  bound  to  a  few  specific  principals,  often  just  one.  We  call  them  anchored 
roles  and  denote  them  as 

PA 

Here,  the  role  owner  A  is  an  actual  principal  name,  a  constant.  Other  roles  can  be  executed  by  any  principal.  In  these  cases  A 
must  be  kept  as  a  parameter  bound  to  the  role.  We  use  the  following  syntax  to  represent  these  generic  roles: 


where  the  implicitly  typed  universal  quantification  symbol  implies  that  A  should  be  instantiated  to  a  principal  before  any  rule 
in  p  is  executed,  and  sets  the  scope  of  the  binding  to  p.  Observe  that  in  this  case  A  is  a  variable.  With  a  slight  abuse  of 
notation,  we  will  sometimes  refer  to  roles  of  either  kind  with  the  letter  p,  variously  subscripted. 


We  will  present  the  type-checking  rules  for  roles  after  the  notion  of  protocol  theory  has  been  formalized  in  Section  4.3 


4.3  Protocol  Theories 

A  protocol  theory,  written  V,  is  a  finite  collection  of  roles: 

Protocol  theories:  V  ::=  •  (Empty  protocol  theory) 

V ,  p^A  (Extension  with  a  generic  role) 

V ,  pA  (Extension  with  an  anchored  role) 

It  should  be  observed  that  we  do  not  make  any  special  provision  for  the  intruder.  The  adversary  is  expressed  as  one  or  more 
roles  in  the  same  way  as  the  more  legitimate  message  exchange  in  a  protocol.  We  will  illustrate  in  Section  [9]  how  this  is 
achieved  for  the  standard  Dolev-Yao  intruder. 

The  validity  of  a  protocol  theory  is  checked  against  the  current  signature.  This  is  an  indication  that  roles  containing  free 
variables  will  not  type-check,  and  therefore  are  not  to  be  considered  valid.  The  following  judgment  expresses  this  relation: 

E  h  V  V  is  a  valid  protocol  theory  in  signature  E 

The  rules  implementing  this  judgment  are  given  below.  They  essentially  reduce  the  validity  of  a  protocol  theory  to  the 
validation  of  the  rule  collections  within  roles,  expressed  by  the  judgment  T  h  p. 

E  h  V  (E,A  :  principal)  h  p 

-  htp_dot  -  htp_grole 

Eh-  E  h  V,pJA 
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(E,  A  :  principal,  E')  h  V  (E,  A  :  principal,  E')  h  p 

-  htp_arole 

(E,  A  :  principal,  E7)  h  V,pA 

Observe  the  difference  in  the  way  the  signature  is  used  in  rule  htp.grole  and  htp_arole.  In  the  former,  A  is  a  variable,  and 
therefore,  the  assumption  “A  :  principal”  is  added  to  the  signature  E,  with  the  effect  of  invoking  the  role  validation  judgment 
with  a  typing  context.  The  latter  rule  instead  checks  whether  the  signature  at  hands  has  a  record  that  the  constant  A  has  type 
principal:  the  role  validation  judgment  is  called  with  a  signature. 

We  conclude  this  section  by  stating  and  proving  decidability  results  for  type-checking  roles  and  protocol  theories. 

Property  4.2  Whenever  the  subsorting  relation  t  ::  t'  is  a  well-order,  it  is  decidable  whether  the  judgments  T  h  p  and 
E  h  V  hold. 

Proof:  A  role  is  a  finite  collection  of  rules  with  a  distinguished  constant  or  variable  (the  role  owner).  Type-checking  a  role 
reduces  then  to  validating  its  rules,  which  is  decidable. 

The  second  judgment  reduces  to  the  first  since  a  protocol  theory  consists  of  finitely  many  roles.  □ 


4.4  Active  Roles 

As  we  will  see  in  Section[6]  several  instances  of  a  given  role,  possibly  stopped  at  different  rules,  can  be  present  at  any  moment 
during  execution.  We  record  the  role  instances  currently  in  use,  the  point  at  which  each  is  stopped,  and  the  principal  who 
is  executing  them  in  an  active  role  set.  These  objects  are  finite  collections  of  active  roles,  i.e.  partially  instantiated  rule 
collections,  each  labeled  with  a  principal  name.  The  following  grammar  captures  their  macroscopic  structure: 

Active  role  sets:  R  ::=  ■  (No  active  role) 

R ,  pA  ( Extension  with  an  instantiated  role) 

The  notation  pk  is  reminiscent  of  anchored  roles.  Active  roles  are  actually  more  liberal  in  that  some  of  the  role  state  predicate 
symbols  as  well  as  their  arguments  may  be  instantiated.  Intuitively,  pA  results  from  instantiating  the  contents  of  some  role, 
with  A  is  its  elected  owner. 

Typing-checking  active  role  sets  is  achieved  by  means  of  the  following  judgment: 

EhJl  R  is  a  valid  active  role  set  in  signature  E 

and  implemented  by  the  following  two  typing  rules: 

(E,A  :  principal,  E')  h  R  (E,A  :  principal,  S')  h  p 

- atp.dot  -  atp.ext 

E  h  •  (E,A:  principal,  S')  h  R,  pA 

Active  role  sets  are  type-checked  with  respect  to  signatures,  and  therefore  they  must  be  ground  in  order  to  be  valid.  In  rule 
atp_ext,  we  first  verify  that  the  role  owner  A  is  an  actual  principal  declared  in  the  signature.  Then  we  check  in  the  right-hand 
premise  that  p  is  a  valid  rule  collection.  It  should  be  observed  that  this  will  proceed  slightly  differently  than  if  we  were 
checking  an  anchored  role,  although  the  calls  look  very  alike:  indeed  p  will  in  general  be  more  instantiated  than  an  anchored 
role  and  possibly  have  declared  constants  for  role  state  predicate  symbols.  Since  the  typing  rules  that  verify  the  antecedent 
and  the  consequent  rely  ultimately  on  the  state  validation  judgment,  this  is  processed  transparently. 

Verifying  the  validity  of  an  active  role  set  is  decidable,  as  stated  by  the  following  property: 

Property  4.3  Whenever  the  subsorting  relation  t  ::  t'  is  a  well-order,  it  is  decidable  whether  the  judgment  E  h  R  holds. 

Proof:  Validating  an  active  role  set  ultimately  reduces  to  a  finite  number  of  uses  of  the  type-checking  judgment  for  rules, 
which  we  have  proved  decidable.  □ 
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4.5  Changes 


It  should  be  noted  that  the  above  syntax  of  rules  is  much  more  liberal  than  the  original  definition  of  MSR  II27II30I1.  We  dedicate 
the  remainder  of  this  section  to  commenting  on  these  differences.  We  begin  by  noting  structural  changes  (items  [l]-[3]l,  then 


move  to  persistent  information  (item|4|,  memory  predicates  (item 
a  number  of  remarks  concerning  the  role  state  predicates  (items  17 


,  and  network  predicates  (item|6]i.  We  then  continue  with 
3,  and  conclude  with  active  roles  (item [IT]). 


1.  A  protocol  theory  was  defined  in  |27J[3D)  as  a  collection  of  rules  for  which  the  graph  generated  by  their  role  state 
predicates  was  acyclic  (see  item  10  below  for  further  details).  Each  connected  component  corresponded  to  a  role. 
Besides  this  constraint,  the  rules  within  a  role  were  independent.  This  aspect  is  mostly  maintained  in  our  current 
formulation,  but  our  definition  of  role  allow  threading  rules  by  using  role  state  predicate  declarations  as  a  sequencing 
device.  This  option  is  seldom  used  since  this  effect  can  be  achieved  more  simply  by  appropriately  using  role  state 
predicates. 


2.  In  l27l[30ll,  all  variables  were  implicitly  universally  quantified  at  the  head  of  a  rule,  unless  marked  in  the  consequent  as 
fresh  data.  Here,  these  variables  are  explicitly  introduced  by  typed  universal  quantifiers.  Explicit  quantification  simpli¬ 
fies  rule  analysis  as  far  as  type-checking  and  data  access  specification  are  concerned.  More  importantly,  it  declares  the 
type  of  variables,  which  is  necessary  for  the  correct  execution  of  a  protocol  (more  on  this  aspect  in [6]).  In  Section 
we  will  see  how  many  quantifiers  and  typing  declarations  can  be  omitted  while  writing  protocol  specifications,  and  be 
reconstructed  during  type-checking. 


7.1 


3.  The  only  quantifiers  present  in  (27][30'|  appeared  in  rule  consequents  and  had  the  purpose  of  introducing  variables  to 
be  instantiated  with  fresh  data.  The  adoption  of  dependent  types  makes  this  mechanism  more  powerful.  Our  current 
schema  allows  for  example  a  server  to  generate  a  key  to  be  shared  among  two  specific  principals. 

4.  As  already  observed,  our  current  formulation  does  not  make  use  of  the  persistent  predicates  of  03  ED-  As  we  said, 
the  information  once  conveyed  by  these  objects  is  not  entirely  captured  within  the  type  system  of  MSR. 


5.  Memory  predicates  are  a  novel  feature.  As  already  mentioned,  they  are  useful  whenever  data  should  be  remembered 
across  role  executions,  which  happens  when  a  subprotocol  can  be  executed  repeatedly  after  some  initialization  phase. 


6.  Any  number  of  network  predicates  can  appear  in  both  the  antecedent  and  the  consequent  of  a  rule.  The  original 
definition  allowed  at  most  once  such  predicate  per  rule,  either  in  the  left-hand  side  (in  “receive”  rules),  or  in  the  right- 
hand  side  (for  “send”  rules).  Denker  et  al.  Il42l  showed  that,  whenever  some  simple  conditions  are  met,  a  sequence  of 
contiguous  message  reception  rules  followed  by  a  sequence  of  contiguous  transmission  rules  can  be  soundly  collapsed 
into  a  single  rule  of  the  proposed  form.  This  is  clearly  a  conservative  extension  of  our  previous  proposal.  Its  practical 
value  is  in  reducing  the  length  of  the  specification  of  a  protocol. 

7.  In  ll27l  |30l,  each  rule  contained  exactly  one  role  state  predicate  on  each  side,  with  the  exception  of  the  single  “role 
generation  rule”  that  activated  the  role.  The  productions  above  instead  allow  zero,  one,  or  several  such  predicates  on 
either  side.  This  definition  simplifies  the  grammatical  specification  of  roles  without  complicating  the  typing  and  data 
access  specification  rules.  However,  we  will  make  a  very  limited  use  of  this  added  expressive  power.  Having  more 
than  one  role  state  predicate  in  the  left-hand  or  right-hand  side  of  a  rule  does  not  appear  particularly  useful  since,  as  we 
will  see  in  Section  [5]  the  arguments  of  these  predicates  collect  all  the  data  known  to  a  principal  in  the  current  thread 
of  execution  of  a  role.  The  antecedent  of  the  first  rule  in  a  role  cannot  sensibly  mention  any  role  state  predicate  since 
its  left-hand  side  could  not  match  any  state.  The  antecedent  of  the  other  rules  typically  will  have  such  a  predicate  for 
synchronization,  although  this  is  not  enforced.  For  the  same  reason,  the  consequent  of  a  rule  will  generally  contain  a 
role  state  predicate.  The  natural  exception  to  this  practice  regards  the  final  rules  of  a  role,  which  do  not  need  to  make 
provisions  for  further  synchronization. 

8.  The  role  state  predicate  symbols  allowed  in  127II30I  were  constants  rather  than  variables.  We  now  prefer  to  make  them 
unique  to  each  instantiation  of  a  rule  in  order  to  avoid  the  possibility  of  interferences  (although  we  have  no  examples 
in  which  such  a  phenomenon  is  harmful). 
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9.  With  the  exception  of  (30),  our  previous  work  did  not  refer  to  any  argument  of  a  role  state  predicate  as  a  distinguished 
role  owner.  The  objectives  of  these  early  versions  of  MSR  did  not  actively  rely  on  role  owners,  and  therefore  no 
particular  emphasis  was  given  to  this  notion.  This  information  becomes  crucial  when  trying  to  enforce  data  access 
specification  as  we  will  do  in  Section[5] 

10.  For  any  given  role,  it  is  interesting  to  study  the  graph  whose  nodes  are  its  role  state  predicates  and  whose  edges  link  the 
predicate  occurring  in  the  left-hand  side  to  the  predicate  in  the  right-hand  side  of  each  rule.  In  1)27]  !30l  |3T~I  we  required 
that  this  graph  be  an  upper  semi-lattice,  and  in  particular  that  it  had  a  single  entry  point  and  be  acyclic.  This  was  a 
crucial  assumption  for  studying  the  complexity  of  protocols  (27ll46l.  Here,  we  drop  this  condition  from  the  syntax  of 
a  role,  but  our  bring  rules  will  de  facto  implement  a  similar  constraint  at  execution  time. 

1 1 .  Our  previous  work  ESSO)  did  not  have  a  notion  of  active  role:  since  role  state  predicate  symbols  were  constants,  rules 
could  not  be  threaded  within  a  role  and  each  rule  was  necessarily  an  independent  object  that  could  be  applied  whenever 
its  antecedent  matched  the  current  state.  The  more  complex  pattern  proposed  in  this  chapter  require  memorizing  which 
roles  are  in  current  use,  and  how  they  are  instantiated.  This  is  the  purpose  of  active  role  sets. 


5  Data  Access  Specification 


Type-checking  allows  statically  verifying  that  language  expressions  are  constructed  in  accordance  to  the  intended  functional¬ 
ity  of  the  objects  that  constitute  them.  For  example,  it  can  be  used  to  catch  such  errors  as  the  encryption  of  a  message  with  a 
tuple,  or  even  with  a  nonce.  It  applies  to  all  aspects  of  the  encoding  of  a  protocol,  from  state  components,  to  rules,  to  types 
themselves.  The  underlying  idea  is  that  expressions  that  violate  the  typing  policy  cannot  be  part  of  the  specibcation  of  a  valid 
protocol:  they  are  therefore  meaningless. 

We  will  now  use  the  typing  declarations  of  MSR  to  further  restrict  the  spectrum  of  sensible  expressions,  in  particular  as 
far  as  protocol  rules  are  concerned.  Indeed,  well-typing  does  not  prevent  a  rule  from  looking  up  and  using  information  its 
owner  should  not  have  access  to.  For  example,  the  fact  that  principal  A  is  initiating  a  session  with  B  shall  not  allow  him/her 
to  access  a  key  that  B  shares  with  a  server.  Similarly,  the  owner  of  a  role  should  clearly  be  able  to  access  his/her  own  memory 
predicates,  but  not  those  of  any  other  party. 


In  this  section,  we  will  formalize  and  implement  these  various  requirements  (and  others)  by  means  of  statically  checkable 
data  access  specification  judgments.  Data  access  veribcation  and  type-checking  are  independent  procedures,  nonetheless  it 
will  be  convenient  to  assume  that  all  the  expressions  we  will  be  analyzing  are  well-typed,  since  it  simplibes  the  discussion. 
It  should  be  observed  that  this  way  of  organizing  our  presentation  does  not  entail  that  validating  a  protocol  specibcation 
requires  two  passes:  both  typing  (actually  type  reconstruction,  see  Section [TTI)  and  data  access  specibcation  can  take  place 
simultaneously.  The  resulting  judgments  and  combined  inference  rules  would  become  however  more  complex  and  we  leave 
their  write-up  to  the  interested  reader. 


In  Sections  [2j|4]  we  incrementally  introduced  the  syntax  and  typing  rules  of  MSR  starting  from  the  most  basic  entities 
(atomic  messages)  and  building  on  our  own  work  as  we  presented  more  complex  constructions  (ultimately  protocol  theories). 
Now  that  the  syntax  has  been  debned,  we  believe  that  we  can  attain  better  clarity  by  moving  in  the  inverse  direction:  in 
the  following,  we  will  initially  present  the  data  access  specibcation  judgments  and  inference  rules  for  macroscopic  objects 
such  as  protocol  theories  and  roles,  but  only  later  describe  how  data  access  specibcation  is  enforced  on  their  components. 
Therefore,  the  premises  of  inference  rules  will  sometimes  mention  a  judgment  that  has  not  yet  been  formally  debned.  We 
will  indicate  such  occurrences  by  enclosing  them  in  a  gray  box .  In  all  such  cases,  we  will  give  ample  warnings  and  enough 
explanations  in  the  text  to  permit  understanding  these  rules.  Given  this  disclaimer,  the  remainder  of  our  discussion  on  data 
access  specibcation  is  organized  as  follows:  in  Section  5.1  we  discuss  data  access  specibcation  for  protocol  theories,  roles, 
and  individual  rules.  In  Section  15.21  we  concentrate  on  the  left-hand  side  of  a  rule,  where  most  information  is  gathered. 

k4l 


Section  5.3  focuses  instead  on  rule  consequents.  In  Section  [5T4]  we  slightly  extend  the  discussion  to  enforce  data  access 
specibcation  on  active  roles.  In  Section  [575]  we  show  that  checking  data  access  specibcation  is  decidable.  We  conclude  in 
Section  [5?6|by  listing  the  changes  with  respect  to  earlier  versions  of  MSR. 
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5.1  Protocol  Theories  and  Roles 


In  this  section,  we  present  the  highest  (and  simplest)  levels  of  data  access  specification:  we  describe  how  protocol  theories. 


roles  and  rules  are  processed,  leaving  the  treatment  of  the  antecedent  and  consequent  of  a  rule  for  Sections  5.2  and  5.3  respec¬ 
tively.  We  conclude  by  defining  the  notion  of  knowledge  context,  which  underlies  our  data  access  specification  verification 
procedure. 

The  following  judgment  expresses  the  fact  that  a  protocol  theory  V  realizes  correct  data  access  specification  with  respect 
to  a  signature  E. 


E  lb  V 


Protocol  theory  V  implements  valid  data  access  specification  in  signature  E 


This  judgment  is  implemented  by  the  following  three  inference  rules,  corresponding  to  the  three  productions  in  the  syntax  of 
a  protocol  theory.  The  right-hand  premise  of  rules  hac  grole  and  liac  arole  invoke  the  data  access  specification  judgment 
‘T  1 1-^  p”  for  rule  collections,  that  will  be  introduced  shortly. 


-  hac_dot 

E  Ih  • 


E  Ih  V  (E,  A  :  principal)  lhA  p 

-  hac_grole 

E  Ih  P,pyA 


E  Ih  V  E  Ih A  p 

- hac_arole 

E  Ih  V,pA 


Rule  hac_dot  trivially  validates  the  empty  protocol  theory.  Observe  that  the  central  rule,  which  applies  to  generic  roles, 
pushes  the  declaration  for  the  role  owner  A  in  E,  with  the  effect  of  invoking  its  right-hand  premise  with  a  typing  context. 
Rule  hac_arole  deals  with  anchored  roles.  It  may  appear  surprising  that  we  do  not  check  that  A  is  declared  in  its  signature  as 
a  principal.  Remember  however  that  we  are  working  under  the  assumption  that  all  expressions  are  well-typed,  therefore  we 
know  by  rule  htp_arole  from  Section  4.3  that  E  includes  a  declaration  of  the  form  “A  :  principal”. 


Since  data  access  specification  is  about  what  information  the  owner  of  a  role  is  entitled  to  access,  it  should  come  at  no 
surprise  that  the  judgments  that  operate  on  rule  collections  and  their  components  have  a  principal  as  a  distinguished  parameter. 
We  first  see  this  in  the  following  data  access  specification  judgment  for  rule  collections  themselves,  where  A  is  the  owner  of 
P- 


T  lbA  p  Rule  collection  p  implements  valid  data  access  specification  for  principal  A  in  context  T 

The  inference  rules  implementing  this  judgment  are  given  below.  Again,  their  one-to-one  correspondence  with  the  grammat¬ 
ical  productions  that  define  a  rule  collection  makes  them  syntax-oriented. 

(r,  L  :  f)  IK  p  T  IK  r  T  \\-A  p 

- oac_dot  - oac_rsp  - oac_rule 

r  IK  •  T  IK  3L  :  t.  p  T  IK  r,p 

The  leftmost  rule  deals  with  empty  rule  collections.  Rule  oac_rsp  collects  the  declaration  of  an  existentially  quantified  role 
in  the  context  and  verifies  its  body.  Again,  since  we  operate  on  well-typed  objects,  we  do  not  need  to  check  the  validity  of 
the  tuple  type  t.  The  rightmost  inference  rule,  oac_rule,  implements  the  situation  where  a  collection  starts  with  a  rule  r.  Its 
left  premise  validates  r  itself  by  means  of  the  data  access  specification  judgment  for  rules,  ‘T  K  r”,  that  we  will  describe 
shortly.  The  rest  p  of  the  rule  collection  is  recursively  verified  in  the  right  premise 

The  following  judgment  expresses  valid  data  access  specification  for  rules: 

T  lbA  r  Rule  r  implements  valid  data  access  specification  for  principal  A  in  context  T 

It  is  implemented  by  the  two  rules  given  below.  We  will  dedicate  most  of  the  sequel  to  describing  how  this  is  achieved. 

(r,x  :  r)  IK  r 

uac_core  -  uac_all 

T  lbA  Vx  :  t.  r 

Intuitively,  the  judgment  in  the  left  premise  of  rule  uac.core,  ‘T ;  •  lbA  Ihs  >  ■  A”,  collects  the  data,  t  say,  the  rule  owner 

A  is  given  in  the  left-hand  side  Ihs.  This  includes  network  messages  and  previously  gathered  information  stored  in  memory 


T;-  IK  Ihs  >  •  A  T;  A  IK  rhs 
T  IK  Ihs  — >  rhs 
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or  role  state  predicates.  This  judgment  also  produces  the  knowledge  context  A  (defined  shortly),  which  contains  information 
that  A  can  reasonably  deduce  from  t  and  later  use  in  the  right-hand  side.  Since  it  contains  information  about  which  key 
belongs  to  whom,  etc.,  the  context  T  plays  an  important  role  in  deciding  what  can  legitimately  enter  A.  This  judgment  and 
its  realization  are  the  topic  of  Section  [5T2]  where  we  will  explain  the  meaning  of  the  various  “•”s. 

Informally,  the  judgment  on  the  right  premise  of  this  rule,  ‘T ;  A  lhA  rhs”  uses  the  knowledge  A  produced  by  analyzing 
the  antecedent  to  verify  that  A  can  construct  all  the  messages  mentioned  in  the  right-hand  side  rhs.  This  judgment  and  the 
inference  rules  implementing  it  are  the  subject  of  Section [53] 

Rule  uac  all  collects  the  universal  declaration  prefixing  the  core  of  a  rule  in  the  context. 


We  conclude  this  section  by  introducing  the  notion  of  knowledge  context,  often  simply  referred  to  as  knowledge.  These 
objects  play  an  important  role  in  data  access  specification  verification  for  the  antecedent  and  consequent  of  a  rule.  The 
knowledge  context  of  a  rule  collects  all  the  information  that  its  owner  knows.  As  we  will  see,  this  information  comes  from 
role  state  predicates,  data  stored  in  memory  predicates,  and  messages  received  from  the  network.  It  can  also  contain  data 
deduced  from  all  of  the  above  by  means  of  simple  inferences. 


Well-constructed  rules  remember  the  data  they  have  accessed,  i.e.  their  knowledge,  in  the  arguments  of  their  role  state 
predicates.  Since  these  predicates  can  only  be  applied  to  variables  or  constants  (in  a  rule),  a  knowledge  context  shall  be 
a  collection  of  elementary  terms.  We  will  extend  this  notion  in  Section  5.4  when  describing  our  data  access  specification 
mechanism  for  active  roles. 


Knowledge  contexts:  A 


(Empty  knowledge  context) 

A,  a  (Extension  with  atomic  knowledge) 

A,  x  (Extension  with  parametric  knowledge) 

(...) 


It  will  be  convenient  to  see  knowledge  contexts  as  multisets.  Therefore,  we  may  write  A  =  (A',  e)  to  denote  that  the  variable 
or  constant  e  is  in  A,  even  if  it  is  not  the  last  element  of  A. 

A  knowledge  context  A  is  compatible  with  a  signature  E  if  for  each  term  t  in  A,  there  is  a  type  r  such  that  E  h  r  and 
E-/.:  r. 

As  anticipated,  we  will  dedicate  the  next  section  to  the  treatment  of  the  left-hand  side  of  rules,  and  then  focus  on  their 
right-hand  side  in  Section[53] 


5.2  Accessing  Information  in  the  Left-Hand  Side 

The  left-hand  side  of  a  rule  gathers  the  information  necessary  for  constructing  the  messages  transmitted  or  stored  in  the 
consequent.  The  presence  of  variables  makes  this  process  parametric.  At  execution  time,  pattern  matching  will  instantiate  the 
variables  in  the  antecedent,  and  carry  the  resulting  substitution  to  the  right-hand  side  to  produce  meaningful  output  messages. 
We  will  describe  execution  in  more  detail  in  Section[6] 

The  information  in  the  left-hand  side  of  a  rule  r  consists  of  the  arguments  of  the  role  state  predicates  and  the  data 
embedded  in  the  messages  received  from  the  network  or  retrieved  from  memory  predicates.  We  will  now  take  an  informal 
look  at  each  of  these  sources: 

•  The  arguments  e  =  (e±, . . . ,  en )  of  a  role  state  predicate  L  represent  data  passed  to  a  rule  from  its  logical  predecessor. 
The  owner  of  r,  call  him/her  A,  knows  this  information  because  he/she  has  put  it  there.  These  elementary  symbols 
will  generally  stand  for  principal  names,  keys,  or  nonces,  but  variables  may  also  represent  complex  terms  whose  inner 
values  A  cannot  or  does  not  need  to  access  (e.g.  a  message  encrypted  with  a  key  he/she  does  not  know).  No  matter 
what  they  are  or  are  intended  to  be  instantiated  with,  each  of  the  e,’s  is  an  elementary  piece  of  information  within  the 
rule.  For  example,  even  if  e3  is  a  variable  and  it  is  clear  from  the  protocol  at  hand  that  it  can  only  be  substituted  with 
a  term  of  the  form  {y}k,  the  variable  X3  cannot  be  used  to  access  y,  even  if  e7  is  precisely  k.  (This  form  of  delayed 
message  interpretation  can  easily  be  realized  using  memory  predicates.) 

•  The  expectation  of  a  message  t  from  the  network  is  expressed  by  a  predicate  N(f)  in  the  left-hand  side  of  r.  The  term 
t  will  generally  consist  of  a  number  of  operators  applied  to  variables  (in  rare  occasions  to  constants).  Some  of  the 


20 


5  DATA  ACCESS  SPECIFICATION 


associated  values  are  expected  to  match  previously  known  data  (e.g.  a  nonce  coming  back  from  an  interlocutor),  and 
will  be  represented  by  variables  (or  constants)  listed  in  a  role  state  predicate.  Others  will  be  unknown  (e.g.  a  nonce 
generated  by  an  interlocutor)  and  shall  be  bound  to  previously  unused  variables.  Each  of  these  variables  represents  data 
that  A  is  accessing,  and  that  he/she  will  use  in  the  rule’s  consequent.  The  goal  of  data  access  specification  is  to  make 
sure  that  A  has  legitimate  rights  to  access  this  information. 

•  Finally,  A  can  retrieve  previously  stored  information  from  a  memory  predicate  M  4  (/).  As  for  network  messages,  each 
term  in  t  may  consist  of  a  series  of  constructors  applied  to  variables.  Again,  writing  an  argument  in  this  way  means 
accessing  the  subcomponents  corresponding  to  each  constant  or  variable,  with  the  option  of  using  them  in  the  right-hand 
side.  Observe  that  the  fact  that  A  generated  M  4(f)  does  not  automatically  grant  him/her  access  to  the  submessages  of 
t.  For  example,  the  third  argument  t3  may  have  the  form  {{ t }} k :  A  is  entitled  to  access  t  only  if  he/she  is  in  possession 
of  the  private  key  corresponding  to  k.  Again,  we  must  ascertain  that  A  can  legitimately  access  this  information. 


In  this  section,  we  will  ultimately  devise  a  procedure  that  certifies  that  A  is  entitled  to  access  all  the  elementary  terms 
mentioned  in  the  antecedent  of  a  rule  r.  This  proceeds  in  two  phases:  first  we  collect  the  arguments  of  all  the  predicates  in  the 
left-hand  side  of  r;  how  this  is  done  is  explained  in  Section|5.2.1  The  second  step  involves  breaking  the  composite  messages 
gathered  in  this  way  into  their  elementary  components  (variables  and  constants).  This  is  illustrated  in  Section  5.2.2  The  most 
sensitive  aspect  of  this  phase  is  making  sure  that  A  has  access  to  the  keys  needed  to  decipher  encrypted  messages.  We  isolate 
this  critical  check  in  Sectionl5.2.3l 


5.2.1  Collecting  Arguments 


In  this  section,  we  present  judgments  and  inference  rules  aimed  at  collecting  the  arguments  of  the  predicates  in  the  left-hand 
side  of  a  rule.  This  information  will  be  further  processed  in  Section  5.2.2  We  will  rely  on  the  following  fairly  complex 
judgment: 


T;  A  lb  Ihs  >  t  A' 


Given  knowledge  A,  predicate  sequence  Ihs  and  terms  t, 
principal  A  can  knows  A'  in  context  T 


The  various  meta-variables  are  interpreted  as  follows:  A  is  the  owner  of  the  rule  r  whose  left-hand  side  we  are  analyzing. 
T  is  the  typing  context  of  r.  The  predicate  sequence  Ihs  is  the  portion  of  the  antecedent  of  r  that  has  still  to  be  examined. 
The  terms  t  are  the  arguments  that  have  been  gathered  so  far  and  that  may  need  further  processing.  The  input  knowledge 
context  A  lists  the  collected  arguments  that  are  known  to  be  elementary.  Finally,  the  output  knowledge  context  A'  stands  for 
the  elementary  information  that  will  ultimately  be  extracted  from  r’s  left-hand  side  (i.e.  all  the  variables  and  atomic  constants 
that  appear  in  it).  It  is  convenient  to  interpret  this  judgment  operationally  as  a  partial  function  that  given  A,  l\  Ihs  and  A 
computes  a  value  for  A'  if  the  data  access  specification  policy  is  obeyed.  It  will  be  convenient  to  interpret  t  as  a  multiset. 

As  we  start  processing  the  antecedent  of  a  rule,  A  and  t  are  empty  (written  “•”)  as  no  argument  has  yet  been  collected. 
This  explains  the  left  premise  of  rule  uac_core  in  Section  [5~T| 

Our  first  rule  describes  how  a  role  state  predicate  L(A,  e)  is  processed.  Remember  that,  by  definition,  L  is  a  parameter, 
its  first  argument  A  is  a  principal  name,  and  the  terms  (A,  e)  must  be  either  constants  or  variables  (recall  also  that  we  assume 
to  be  working  with  well-typed  objects).  Therefore,  each  object  among  (A,  e)  is  an  elementary  piece  of  information.  We  can 
therefore  merge  (A,  e)  into  the  current  input  knowledge  context  A  and  use  the  resulting  knowledge  context  A'  to  analyze  the 
remaining  predicates  Ihs.  We  have  the  following  rule,  which  makes  use  of  the  merge  judgment  “A  >  e  >  A'”  which  we 
will  explain  shortly: 

A  >  (A,  e )  >  A'  T;  A'  lb  Ihs  >  t'  »  A" 

-  lac_rsp 

T;  A  lb  (L(A,  e),  Ihs )  >  t'  »  A" 

This  rule  applies  only  if  the  first  parameter  of  the  role  state  predicate  symbol  L  is  the  owner  of  the  rule  under  examination. 

We  next  turn  to  network  predicates  in  the  antecedent  of  a  rule.  Since  the  received  message  t  may  not  be  elementary,  we 
shall  include  it  in  the  list  of  unprocessed  arguments  t'  before  examining  the  remaining  predicates  Ihs.  We  have  the  following 
rule: 

T;  A  lb  Ihs  >  (t,P)  »  A" 

- lac_net 

T;  A  lb  (N(f),  Ihs)  >  t'  >  A" 
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Memory  predicates  are  handled  similarly.  We  shall  however  make  sure  that  the  owner  A  of  the  currently  examined  rule 
does  not  try  to  access  information  gathered  by  another  principal.  Therefore,  only  memory  predicates  of  the  form  M  4  (t)  will 
be  processed. 

T;  A  11-^  Ihs  >  ( t,t ')  A' 

-  lac_mem 

T;  A  Ih*  (MA(t),lhs)  >f»  A' 

In  this  rule,  we  are  slightly  abusing  our  notation  by  interpreting  the  tuple  t  as  a  multiset  to  be  merged  with  t  ’  (the  comma 
is  indeed  a  different  constructor  for  these  two  entities).  This  can  easily  be  corrected  by  defining  a  judgment  and  two  inference 
rules  that  take  each  term  in  t  in  turn  and  adds  it  to  t For  the  sake  of  simplicity,  we  leave  formalizing  this  correction  to  the 
strict  readers. 


Since  predicate  sequences  are  multisets,  several  instances  of  the  above  rules  will  in  general  be  applicable  to  a  non-empty 
Ihs.  It  should  be  observed  that  the  order  in  which  they  are  applied  is  irrelevant  to  the  success  of  this  judgment  and  to  the 
calculation  of  the  output  knowledge  A'. 


Once  the  arguments  of  all  the  predicates  on  the  left-hand  side  of  the  rule  have  been  collected,  we  pass  to  the  second  phase 
which  ascertains  that  the  uninterpreted  arguments  t  satisfy  the  data  access  specification  policy.  This  is  done  in  the  following 
rule  by  invoking  the  judgment ‘T;  A  lbA  t  A'”  which  will  be  discussed  in  Section 


5.2.2 


T;  A  lhA  t  >  A' 

- lac_dot 

T;  A  \\-A  ■  >  A' 


It  may  appear  surprising  that  we  insist  in  collecting  the  arguments  of  all  the  message  predicates  in  the  left-hand  side  of  a 
rule  before  attempting  to  break  any  composite  term.  The  alternative,  eagerly  examining  arguments,  is  however  incomplete  in 
general.  Assume  for  example  we  receive  the  following  two  network  messages:  N(fci  {mi}k2)  and  I\l(fc2  {'tti2}k1)-  By  first 
collecting  their  arguments  and  then  decomposing  them,  we  can  clearly  access  the  inner  terms  m  1  and  m2.  However,  if  we 
require  that  the  argument  of  one  predicate  is  fully  processed  before  examining  the  other,  then  neither  of  these  messages  can 
be  exposed. 

We  conclude  this  section  by  defining  the  following  merge  judgment  used  in  rule  lac_rsp: 

A  >  e  >  A'  Merging  context  knowledge  A  and  elementary  term  tuple  e  yields  A' 

This  judgment  is  implemented  by  the  following  three  simple  rules: 

A  >  e  >  A'  A  >  e  >  A' 

- mac_dot  - macukn  - mackn 

A  >  •  >  A  A  >  e,  e  >  (A',e)  (A,e)  >  e,  e  >  (A',e) 

The  rightmost  rule  recognizes  that  the  elementary  term  e  is  already  present  in  the  current  knowledge  context  and  therefore 
does  not  add  it  anew.  It  should  be  observed  that  in  this  situation,  rule  mac.ukn  is  applicable  as  well  and  will  result  in  the 
duplication  of  e  in  the  output  knowledge  context.  Well-written  protocol  specifications  will  seldom  require  such  redundancy, 
however. 

It  should  be  observed  that  the  knowledge  context  A  this  judgment  is  initially  invoked  with  is  empty  (“•”)  unless  the 
antecedent  of  a  rule  contains  more  than  one  role  state  predicate  (as  mentioned  earlier,  we  do  not  anticipate  any  situation 
where  this  would  prove  useful).  Therefore,  we  do  not  expect  a  significant  usage  of  rule  mackn. 


5.2.2  Certifying  Composite  Arguments 

The  previous  section  has  left  open  the  task  of  verifying  that  the  elementary  information  embedded  in  the  composite  messages 
collected  from  the  left-hand  side  of  a  rule  can  actually  be  accessed  by  its  owner.  In  this  section,  we  will  show  how  this  is 


achieved  up  to  the  verification  of  keys,  which  is  the  topic  of  Section  5.2.3 


We  will  rely  on  the  following  judgment  to  examine  possibly  composite  terms.  We  used  it  in  rule  lac_dot  in  the  previous 
section. 


T;  A  lbA  t  >  A' 


Given  knowledge  A  and  terms  t,  principal  A  can  knows  A'  in  context  T 
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The  interpretation  of  each  meta- variable  in  this  judgment  is  inherited  from  the  argument  collection  judgment  in  the  previous 
section:  A  is  the  rule  owner,  T  is  the  typing  context,  A  is  the  input  knowledge,  t  represents  the  terms  that  still  have  to  be 
verified  for  data  access  specification,  and  A'  is  the  output  knowledge  context  extracted  from  t  and  A.  Again,  this  judgment 
can  be  seen  as  a  partial  function  that  computes  a  value  for  A'  when  given  A,  T,  A  and  t,  assuming  that  t  implements  correct 
data  access  specification  for  A.  It  should  be  observed  that  A  has  legitimate  access  to  each  term  in  t:  we  want  to  verify  that 
this  property  extends  to  their  subterms.  Again,  we  interpret  t  as  a  multiset. 

Our  first  two  rules  deal  with  unchecked  elementary  messages.  Thus  the  collection  of  terms  still  to  be  validated  have  the 
form  (e,  £),  where  e  is  either  an  atomic  constant  or  a  variable.  There  are  two  possibility:  either  e  is  known  and  therefore 
appears  in  the  current  input  knowledge,  or  it  must  be  looked  up  in  the  typing  context  T.  In  the  first  case,  implemented  by 
rule  tac_kn,  we  simply  continue  with  the  evaluation  of  t.  In  the  second  case  (rule  tac_ukn),  we  shall  first  add  e  to  the  input 
knowledge  context  used  to  validate  t. 

T;  (A,  e)  lkA  t  »  A'  (T,  e  :  r,  E') ;  (A,  e)  lhA  f»  A' 

- tac_kn  - tac_ukn 

T;  (A,  e)  lhA  e,f»  A'  (T,  e  :  r,  T');A  lhA  e,f»  A' 


Concatenated  messages  can  be  split  unconditionally.  We  need  however  to  recursively  analyze  the  two  submessages  since 
they  may  not  be  elementary. 

T;  A  lbA  A' 


T;  A  lhA  (fi  t2),t  »  A' 


The  rule  owner  A  can  access  the  cleartext  t  of  an  encrypted  message  {£}fe  (or  {{ / }} /,.)  only  if  he/she  is  entitled  to  access  the 
inverse  of  the  encryption  key  k.  This  is  ascertained  by  the  left  premises  of  the  following  rules.  The  judgment  T;  A  lbA  k  >  A' 
(resp.  T;  A  IP A  k  A')  verifies  that  A  can  access  k  (resp.  its  inverse)  and  if  necessary  updates  the  knowledge  context  A  to 
A'.  Once  the  key  has  been  resolved,  the  cleartext  t  is  put  back  in  the  pool  of  pending  messages,  which  is  recursively  analyzed 
in  the  rightmost  premise.  We  will  discuss  the  key  validations  judgments  in  the  next  section. 


r;  A  IPA  k  >  A'  T;  A'  lhA  t,  t  »  A" 

-  tac_ske 

T;  A  lhA  {£}*,£»  A" 


T;  A  IPA  fc>  A'  T;  A'  lhA  t,  t  »  A" 

- tac_pke 

T;  A  lhA  A" 


Once  all  possibly  composite  terms  have  been  reduced  to  their  elementary  constituents  (and  have  been  shown  to  respect 
the  data  access  specification  policy),  we  simply  return  the  input  knowledge  context  that  we  have  been  extending  as  output 
knowledge.  This  is  realized  by  the  following  rule. 


- tac_dot 

r;  a  iha  •  »  a 


5.2.3  Encryption  Keys 

We  conclude  the  treatment  of  the  left-hand  side  of  a  rule  by  devising  a  method  to  establish  when  the  owner  of  a  rule  can 
decipher  (and  therefore  access)  a  message  encrypted  with  a  key  k.  Since  we  assumed  in  Section  [2]  to  have  two  kinds  of 
encryption  operations  (shared-key  and  public-key),  we  will  present  two  judgment  and  the  relative  rules.  It  should  be  noted  that 
richer  schemes,  e.g.  including  digital  signatures  or  a  more  refined  key  taxonomy,  would  need  to  define  additional  judgments 
and  to  provide  the  corresponding  data  access  specification  rules. 

We  shall  begin  with  shared-key  encryption.  We  want  to  decide  when  the  owner  A  of  a  rule  can  access  the  cleartext  £  of  a 
message  {£}j,  encrypted  with  k.  We  express  this  question  by  means  of  the  following  judgment: 

T;  A  k  A'  Given  knowledge  A,  principal  A  can  decipher  a  message 

encrypted  with  shared  key  k  in  context  T 

As  in  previous  judgments,  T,  A  and  A'  are  the  typing  context,  and  the  input  and  output  knowledge  respectively.  Again,  A'  is 
computed  from  the  other  entities  in  this  relation. 
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In  order  for  A  to  decrypt  {/}&,  he/she  must  have  access  to  k  itself  since  we  are  in  a  symmetric-key  setting.  There  are  two 
scenarios  to  analyze  in  order  to  decide  this  judgment.  First,  A  may  know  k,  for  example  if  it  was  previously  transmitted  in 
the  clear.  Then,  k  can  be  found  in  the  input  knowledge  context,  which  is  simply  returned  as  output  knowledge.  We  have  the 
following  rule: 

- kac_ss 

T;  (A,  k)  IPA  k  >  (A,  k) 

The  second  scenario  involves  a  key  A  does  not  know  (yet)  about,  but  to  which  he/she  has  legitimate  access.  A  principal 
has  the  right  to  access  a  shared  key  only  if  this  key  was  intended  to  communicate  with  him/her.  The  following  two  rules 
account  for  this  possibility. 

- kac_sul  - kac_su2 

(T,  k  :  shK  A  B,  T');  A  IPA  k  »  (A,  k)  ( T,k  :  shK  B  A,  T');  A  IPA  k  »  (A,  As) 

Observe  that  the  relationship  between  the  key  owner  and  the  rule  owner  is  encoded  in  the  dependent  type  that  qualifies  the 
key  itself.  Since  k  was  unknown  to  A  but  is  being  accessed,  we  include  it  among  the  output  knowledge  of  these  rules. 

No  other  rules  have  this  judgment  as  their  conclusion.  Therefore,  a  rule  which  attempts  to  decipher  a  message  whose  en¬ 
cryption  key  is  unknown  and  does  not  belong  to  the  rule’s  owner  will  not  pass  this  test.  It  violates  our  data  access  specification 
policy. 

We  now  turn  to  the  case  where  access  to  the  cleartext  t  of  a  message  encrypted  with  public  key  k  has  been  made. 
We  shall  rely  on  the  following  judgment  to  decide  this  situation,  where  the  meaning  of  the  meta-variables  is  as  for  symmetric 
keys: 

T;  A  IPA  k  kp-  A'  Given  knowledge  A,  principal  A  can  decipher  a  message 

encrypted  with  public  key  k  in  context  T 

In  order  to  decipher  a  message  encrypted  with  a  public  key  fc,  we  must  have  access  to  the  corresponding  private  key,  call 
it  k'.  As  in  the  case  of  shared  keys,  the  first  place  where  to  look  is  the  current  knowledge  context.  If  the  private  key  k'  of 
some  principal  B  has  previously  been  encountered,  then  we  can  decipher  transmissions  encoded  with  the  public  key  k.  We 
have  the  following  two  rules,  which  differ  by  whether  k  was  known  to  A  or  not: 


- kac_pss 

(T,  k  :  pubK  B,  T',  k!  :  privK  k,  T");  (A,  k,  k')  IPA  k  »  (A,  k,  k’) 

- kac_pus 

(T,  k  :  pubK  B,  T',  k'  :  privK  k,  T");  (A,  k')  IPA  k  »  (A,  k') 

The  output  knowledge  shall  clearly  include  k!  since  A  must  have  access  to  it  to  perform  the  decryption.  It  may  appear  that 
k  should  always  be  included  in  the  output  knowledge  as  well  since  it  appears  in  the  message  {[  / }} /,  being  deciphered.  This 
is  incorrect:  k  is  needed  to  construct  {{ / }}  k  but  not  to  access  t.  Including  k  would  lead  to  inadequate  specifications  of  key 
distribution  protocols. 

If  A  does  not  know  k! ,  then  he/she  is  entitled  to  access  the  cleartext  of  the  encrypted  message  only  if  he/she  owns 
k  (and  The  following  rules  express  this  possibility.  Again  they  differ  on  whether  A  knows  k,  and  the  above  explanation 
of  why  k  is  not  necessarily  part  of  the  output  context  applies  also  here. 

-  kac_psu 

(T,  k  :  pubK  A,  T',  k'  :  privK  k,  T");  (A,  k)  IPA  k  »  (A,  k,  k') 

- kac.puu 

(T,  k  :  pubK  A,  T',  k'  :  privK  k,  T");  A  IPA  k  >  (A,  k,  k') 

We  shall  again  emphasize  how  data  access  specification  is  built  upon  the  type  declarations  of  MSR ,  and  in  particular  on 
the  notion  of  dependent  types. 
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5.3  Processing  Information  in  the  Right-Hand  Side 


The  right-hand  side  of  a  rule  is  where  messages  are  constructed,  either  to  be  emitted  over  the  public  network,  or  stored  for 
future  use.  However,  the  first  rule  of  an  initiator  role  will  generally  have  an  empty  left-hand  side,  and  yet  it  can  send  complex 
messages  in  its  consequent.  Therefore,  the  right-hand  side  of  a  rule  can  also  access  data  on  its  own,  information  that  is  not 
mentioned  in  its  antecedent.  This  can  happen  in  two  ways:  first  by  generating  fresh  data  (e.g.  nonces),  and  second  by  using 
information  that  is  “out  there”  (e.g.  the  name  of  an  interlocutor,  or  a  key  shared  with  him/her).  This  both  alternatives  have 
the  potential  of  violating  the  data  access  specification  policy  (e.g.  when  trying  to  access  the  private  key  of  a  third  party). 
We  dedicate  this  section  to  enforcing  these  various  forms  of  data  access  specification  in  the  right-hand  side  of  a  rule.  More 
precisely,  Section|5.3.1|analyzes  the  high-level  structure  of  a  rule  consequent,  while  Section|5.3.2|deals  with  the  construction 
of  the  messages  to  be  transmitted  or  stored,  a  major  functionality  of  a  rule’s  right-hand  side.  Finally,  Section  5.3.3  analyzes 
information  access  in  the  right-hand  side  of  a  rule. 


5.3.1  Fresh  Data 

data  access  specification  on  the  right-hand  side  rhs  of  a  rule  r  is  performed  by  the  following  judgment: 

T;  A  lbA  rhs  Right-hand  side  rhs  implements  valid  data  access  specification  for  principal  A 

in  context  T  given  knowledge  A 

where  A  is  the  owner  of  r,  T  is  its  typing  context,  and  A  is  the  knowledge  gained  by  examining  its  antecedent. 

This  judgment  is  implemented  by  rules  whose  number  depends  on  the  intended  application  of  the  protocol  at  hand.  We 
will  first  consider  consequents  prefixed  with  a  fresh  data  declaration,  i.e.  of  the  form  “3x  :  r.  rhs”.  It  is  tempting  to  indiscrim¬ 
inately  add  x  to  the  current  knowledge  context  and  proceed  with  the  validation  of  rhs.  This  is  in  general  inappropriate  since 
it  would  allow  any  principal  to  construct  information  that  can  potentially  affect  the  rest  of  the  system.  In  most  protocols,  no¬ 
body  should  be  allowed  to  create  new  principals.  Similarly,  only  key-distribution  protocols  should  enable  a  principal  to  create 
keys,  and  typically  only  short-term  keys.  On  the  other  hand,  principals  will  generally  be  allowed  to  generate  nonces,  and  in 
a  setting  like  ours,  atomic  messages  (e.g.  an  intruder  may  want  to  fake  a  credit  card  number).  These  considerations  produce 
a  family  of  rewrite  rules  that  differ  only  by  the  type  of  the  existential  declaration  they  consider.  In  all  cases,  we  recursively 
check  the  body  rhs  after  inserting  “x  :  r”  in  the  context  (for  appropriate  r’s)  and  adding  x  to  the  current  knowledge: 

(T,  x  :  nonce);  (A,  x)  lbA  rhs  (T,  x  :  msg);  (A,  x)  lbA  rhs 

-  rac_nnc  -  rac_msg 

F;  A  lbA  3x  :  nonce,  rhs  T;  A  lbA  3x  :  msg.  rhs 

We  must  emphasize  again  that  the  exact  set  of  rules  for  data  generation  depends  on  the  intended  functionalities  of  the  protocol. 
Here,  we  adopt  a  minimalistic  approach  and  do  without  rules  for  keys  and  principals.  Other  settings  may  require  rules  for 
selected  keys. 

Once  all  existential  quantifiers  have  been  stripped  by  uses  of  the  above  rule,  we  are  left  with  a  raw  predicate  sequence 
Uis.  We  invoke  the  predicate  sequence  validation  judgment ‘T;  A  S->A  Ihs”,  discussed  shortly,  to  verify  that  the  inner  core 
Ihs  of  the  rule’s  consequent  satisfies  data  access  specification.  This  is  realized  by  the  following  rule: 


T ;  A  S->A  Ihs 
T;A  lbA  Ihs 


5.3.2  Constructing  Information 

The  main  function  of  a  rule’s  consequent  is  to  constructs  messages,  either  to  be  emitted  over  the  public  network,  or  stored  for 
future  use  in  a  memory  or  role  state  predicate.  In  this  section,  we  turn  our  attention  to  predicate  sequences  that  appear  in  the 
right-hand  side  of  a  rule  and  to  their  embedded  terms. 

The  premise  of  rule  rac_mn  above  included  the  following  judgment: 

T ;  A  S->A  Ihs  Predicate  sequence  Ihs  is  constructible  from  knowledge  A  for  principal  A 
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which  verifies  that  all  the  messages  in  the  predicate  sequence  Ihs,  consisting  only  of  memory  and  network  predicates,  can  be 
constructed  in  the  current  rule.  Clearly,  this  is  based  on  the  accumulated  knowledge  A. 

This  judgment  is  implemented  by  the  following  three  rules  when  Ihs  is  not  empty.  They  rely  on  the  term  constructions 
judgments  “A  S->  t”  and  “A  S->  t  ”  that  will  be  explained  shortly. 

T;  A  S->A  t  T;  A  S-u  Ihs  T;  A  t  T;  A  S-u  Ihs  T;  A  (A,  e )  T;  A  3-u  Ihs 

- rac_net  rac_mem  - rac_rsp 

r;As->A  N(t),lhs  T;A%  M^(f ),lhs  ^As-^  L(A,e),  Ihs 

A  principal  A  is  allowed  to  publish  any  information  he/she  can  construct  on  the  public  network,  but  he/she  shall  be  able  to 
update  only  his/her  own  memory  predicates.  Observe  that  the  first  argument  of  any  role  state  predicate  must  be  the  owner  A 
of  the  rule  it  appears  in. 

Empty  predicate  sequences  are  always  valid.  This  results  from  the  following  simple  rule: 


-  rac_dot 

r;As-u  • 

The  constructability  of  terms  in  the  right-hand  side  of  a  rule  is  expressed  by  the  following  judgment: 

r ;  A  T->4  t  Given  knowledge  A,  principal  A  can  construct  term  t 

Elementary  information  appearing  in  the  right-hand  side  of  a  rule  can  come  from  of  two  sources.  Rule  cac_kn  handles  the 
case  where  it  has  been  collected  in  the  knowledge  context  while  validating  the  antecedent  and  fresh  data  declarations  of  a 
rule.  This  can  also  be  the  first  appearance  of  this  information  in  the  rule,  in  which  case  we  must  verify  that  the  role  owner  is 
effectively  entitled  to  access  it.  This  achieved  in  rule  cac_ukn  through  the  right-hand  side  access  judgment ‘T  9-^  e”,  that 
will  be  discussed  in  Sectionl5.3.3l 

r'H*  e 

- cac_kn  - cac_ukn 

T;  (A,  e)  e  T;  (A,  e)  S-u  e 

Composite  terms  are  recursively  reduced  to  their  atomic  constituents  by  the  following  three  rules: 

T;  A  9-^  ti  T;  A  9-u  t2  T;  A  9->A  t  T;  A  9-^  k  T;  A  9-u  t  T ;  A  k 

-  cac.cnc  - cac_ske  -  cac_pke 

T;  A  9->4  t\t2  T;A%  {/}fc  T;A9->a  § t 

Since  these  rules  depend  on  the  term  constructors  of  the  language  at  hand,  they  shall  be  updated  for  syntaxes  that  include 
additional  operators,  such  as  digital  signatures. 

The  following  judgment  allows  constructing  message  tuples  t  from  the  knowledge  A  at  hand: 

T ;  A  9-u  t  Given  knowledge  A,  principal  A  can  construct  term  tuple  t 

It  is  implemented  by  the  following  two  simple  rules. 


T;  A  t  T ;  A  9->A  t 

-  cac_dot  cac_ext 

r;A^x  •  T;  A  9->A  (t,i) 

5.3.3  Accessing  Information  on  the  Right-Hand  Side 

We  conclude  this  section  by  describing  the  judgment  that  checks  that  a  rule  owner  A  has  legitimate  access  to  elementary  data 
e  that  appear  only  in  the  consequent  of  this  rule.  This  is  achieved  by  the  following  judgment, 

T  9->A  e  Principal  A  can  access  atomic  information  e  in  context  T 
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where  T  is  the  typing  context  in  which  e  is  defined. 

The  implementation  of  this  judgment  depends  entirely  on  the  atomic  data  that  can  be  part  of  a  message  and  therefore 
on  the  types  that  have  been  defined  to  classify  them.  We  will  now  present  inference  rules  relative  to  the  types  defined  in 
Section[2]  but  it  should  be  clear  that  different  type  layouts  will  require  different  rules. 

Let  us  start  with  non-dependent  types.  We  should  clearly  be  able  to  access  any  principal  name,  and  indeed  we  have  the 
following  rule: 

-  eac_pr 

(T,  e  :  principal,  T')  S->A  e 


The  remaining  simple  types  are  nonce  and  msg.  Were  we  to  have  a  rule  similar  to  eac_pr  for  nonces  would  allow  A  to  access 
any  nonce  in  the  system,  including  nonces  that  he/she  has  not  generated.  This  is  clearly  undesirable.  The  only  nonces  A 
is  entitled  to  access  are  the  ones  he/she  has  created  and  the  ones  he/she  has  retrieved  in  received  messages  or  as  previously 
stored  data.  In  all  these  cases,  these  nonces  are  included  in  some  knowledge  context,  and  this  judgment  does  not  need  to  be 
invoked.  A  similar  argument  applies  to  elementary  objects  of  type  msg:  a  rule  akin  to  eac_pr  would  give  A  access  to  any 
message  that  can  be  constructed  in  the  system,  when  invoked  with  a  variable.  This  is  particularly  undesirable  since  msg  is 
a  supersort  of  nearly  all  our  types  (see  Section  2.2 1:  this  would  authorize  A  to  use  all  data  that  can  be  constructed  in  the 
signature  the  rule  is  executed  in. 

Next,  let  us  consider  shared  keys.  Clearly,  A  should  have  free  access  to  all  of  his/her  shared  keys,  but  to  no  others.  This 
is  expressed  by  the  following  two  rules: 


-  eac_sl 

(T,e  :  shK  A  B,  T')  e 


-  eac_s2 

(T,e  :  shK  B  A,  T')  T-u  e 


A  similar  argument  holds  for  asymmetric  keys:  A  has  legitimate  access  to  all  of  his/her  private  keys,  and  to  the  public 
keys  of  any  principal. 


(T,  e  :  privK  k ,  T',  k  :  pubK  A,  T")  e 


eac_pp 


(T,  e  :  pubK  B,  T')  S->A  e 


eac_p 


It  should  be  observed  that  protocols  that  make  use  of  a  key  distribution  center  should  not  rely  on  these  rules.  These  kind 
of  protocols  require  a  language  and  type  layout  that  is  more  elaborate  than  the  one  in  our  running  example. 

This  concludes  the  presentation  of  the  data  access  specification  judgments  and  rules  for  protocol  rules  and  the  syntactic 
entities  they  are  part  of,  i.e.  roles  and  protocol  theories.  We  will  collect  all  this  sparse  information  in  Appendix  [A]  We  will 
prove  decidability  results  for  these  judgments  in  Section  5.5  We  shall  first  extend  the  discussion  we  just  concluded  to  active 
roles. 


5.4  Active  Roles 


In  Section |4~4|  we  defined  an  active  role  as  a  role  suffix  whose  free  variables  have  been  instantiated  to  ground  terms.  They 
correspond  to  roles  in  the  midst  of  execution.  Active  roles  should  clearly  be  subject  to  the  same  access  constraints  as  protocol 
theories,  and  this  section  will  be  dedicated  to  showing  how  this  is  achieved. 


Intuitively,  active  roles  are  handled  by  allowing  ground  terms  anywhere  variables  can  appear  in  a  role,  and  by  treating 
them  in  the  same  way.  We  start  therefore  by  updating  the  notion  of  knowledge  context  from  Section  5.1  as  follows: 


Knowledge  contexts:  A 


(Empty  knowledge  context) 

A,  a  (Extension  with  atomic  knowledge ) 

A,  x  (Extension  with  parametric  knowledge) 
A,  t  (Extension  with  ground  terms) 


Here,  t  stands  for  a  ground  term  that  has  been  substituted  for  a  variable.  Observe  that  active  roles  may  contain  bound  variables 
that  have  yet  to  be  instantiated.  For  this  reason,  we  still  include  variables  in  the  above  definition. 

As  suggested  above,  instantiating  terms  shall  be  treated  exactly  in  the  same  way  as  elementary  information  in  the  previous 
section.  Therefore,  we  will  examine  in  turn  all  the  data  access  specification  rules  that  use  elementary  terms  and  produce  a 
version  that  can  deal  with  active  roles. 


27 


5  DATA  ACCESS  SPECIFICATION 


We  start  with  rule  lac_rsp  which  added  the  arguments  of  a  role  state  predicate  in  a  rule’s  antecedent  to  the  current 
knowledge  context.  By  systematically  replacing  “e”  with  “t”,  we  obtain  the  following  variant: 

A  >  (A ,t)  >  A'  T;  A'  lbA  Ihs  >  t'  >  A" 

- lac_rsp* 

T;  A  lbA  (L(A,  t),  Ihs)  >  t'  »  A" 

Since  role  state  predicated  parameters  may  have  been  instantiated  in  an  active  roles,  L  here  should  be  interpreted  as  a  constant 
or  a  variable.  Observe  that  the  arguments  (A,  f)  of  L  are  inserted  in  the  current  knowledge  context  while  the  arguments  of 
the  network  and  memory  predicates  are  introduced  in  the  central  area  of  this  judgment.  This  implies  that  composite  elements 
of  t,  cannot  be  broken  into  elementary  pieces.  This  is  sensible  since  they  are  ground  instantiations  of  variables,  and  a  rule  has 
no  access  to  the  expected  structure  of  its  variables. 

Next,  we  need  to  update  the  implementation  of  the  merge  judgment  that  appears  in  the  left  premise  of  rule  lac  rsp*.  We 
have  the  following  two  rules: 

A  >  t  >  A' 

-  mac_ukn* 

A  >  t,t  >  (A \t) 

The  next  rule  to  upgrade  is  tac_kn  that  checked  for  known  pieces  of  elementary  information  in  memory  or  network 
predicates.  In  an  active  role,  such  a  term  could  have  been  the  result  of  instantiation.  Therefore,  we  must  allow  it  to  be  looked 
up  in  the  current  knowledge  context.  We  obtain  the  following  rule: 

T;  (A,  t)  lbA  f»A' 

- tac_kn* 

T;  (A,  t)  lbA  i,i»  A' 

We  now  move  to  the  right-hand  side  and  to  rule  rac  rsp,  which  updated  the  current  knowledge  with  pieces  of  information 
appearing  for  the  first  time  in  a  role  state  predicate  in  a  rule’s  consequent.  As  usual,  it  suffices  to  upgrade  the  e’s  to  f’s,  which 
yields  the  following  data  access  specification  rule  (again,  L  may  be  either  a  parameter  or  a  role  state  predicate  constant): 

r;A%  (A,i)  TjAS-^  Ihs 

- rac_rsp* 

r;AS->A  L(A,F),//is 

Our  last  upgrade  involves  rule  cac  gen,  which  enabled  constructing  an  object  consisting  of  a  previously  known  elemen¬ 
tary  message.  We  simply  need  to  extend  it  to  arbitrary  ground  terms: 

-  cac_gen* 

(A,  t)  S->  t 

We  may  expect  a  similar  update  for  rule  cac  iikn,  which  checks  whether  information  not  previously  seen  can  be  accessed 
to  construct  a  term  in  the  right-hand  side  of  a  rule.  We  observed  in  Section  [533]  that  the  implementation  of  the  judgment 
‘T  <ha  e”  depends  on  the  term  language  in  use.  In  our  case  study,  we  argued  that  this  judgment  can  be  fulfilled  only  if  e 
is  a  principal  name,  one  of  ,4’s  shared  or  private  keys,  or  an  arbitrary  public  key.  When  dealing  with  an  active  role  pA,  it 
may  be  tempting  to  accept  more  complex  terms  t.  in  this  position:  for  example  the  concatenation  of  a  principal  name  and  his 
public  key  seems  completely  innocuous.  Nonetheless,  we  will  disallow  these  possibilities:  if  t  is  a  composite  term,  it  has  type 
msg  and  can  only  result  from  the  instantiation  of  some  variable  Therefore,  the  role  p  from  which  pA  descends  contains  a 
variable  x  of  type  msg  that  appears  for  the  first  time  in  the  right-hand  side  of  one  of  its  rules.  This  rule  would  violate  our  data 
access  specification  policy  since  x  could  have  been  instantiated  to  a  term  A  does  not  have  access  to.  If  p  is  part  of  the  protocol 
theory  V  that  models  some  protocol  under  analysis,  the  data  access  specification  judgment  £  \\-  V  would  not  be  satishable. 

In  summary,  our  case  study  does  not  require  modifying  the  judgment ‘T  S->A  e”  that  checks  whether  A  can  be  granted 
access  to  an  object  e  that  appears  for  the  first  time  in  the  right-hand  side  of  a  rule.  However,  more  complex  languages  may 
need  to  make  changes  to  the  implementation  of  this  judgment  that  apply  only  to  active  roles. 

The  infrastructure  in  which  the  above  upgrades  take  place  has  been  kept  informal  for  the  sake  of  clarity.  Clearly  these  rule 
variants  are  applicable  only  when  examining  an  active  role,  and  should  not  be  used  for  validating  the  data  access  specification 


A  >  t  >  A' 

- mac_kn* 

(A ,t)  >t,t>  (A ',*) 
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policy  in  a  rule.  A  precise  way  to  enforce  this  distinction  is  to  create  an  active  role  version  of  each  of  the  involved  judgments, 
and  to  accordingly  duplicate  all  the  original  rules  (with  new  names).  We  leave  this  as  an  exercise  to  the  zealous  reader. 

We  now  introduce  the  following  judgment,  that  expresses  the  fact  that  an  active  role  set  satisfies  our  data  access  specifi¬ 
cation  policy  in  the  current  signature: 

E  lb  R  Active  role  set  R  implements  valid  data  access  specification  in  signature  E 

It  is  implemented  by  the  following  two  simple  rules,  where  the  right  premise  of  rule  aac_ext  calls  the  variant  of  the  rule 
collection  data  access  specification  judgment  for  active  roles: 


-  aac_dot 

E  lb  • 


E  lb  R  E  lb A  p 

- aac.ext 

E  lb  R,pA 


5.5  Decidability  of  Data  Access  Specification 


We  continue  this  introduction  to  data  access  specification  in  MSR  by  proving  that  all  the  judgments  presented  in  this  section 
have  decidable  implementations.  Furthermore,  we  will  show  that  the  judgments  to  which  we  have  ascribed  a  functional 
behavior  implement  computable  relations. 


For  simplicity,  we  will  structure  this  presentation  as  follows:  we  will  prove  the  decidability  results  concerning  the  an¬ 
tecedent  and  consequent  of  a  rule  in  Sections  5.5.1  and  5.5.2  respectively.  We  will  then  put  these  properties  together  in 
Section  5.5.3  to  produce  analogous  results  for  roles  and  protocol  theories.  Finally,  we  extend  these  findings  to  active  role 
sets  in  Section[5.5.4|  Throughout  this  section,  it  will  be  convenient  to  assume  that  we  are  exclusively  working  with  typable 
objects.  Clearly,  a  knowledge  context  is  typable  if  all  the  contained  terms  are  well-typed  in  the  current  signature  or  typing 
context. 


5.5.1  Deciding  the  Left-Hand  Side  Judgments 


Before  tackling  the  task  of  proving  computability  issues  about  the  numerous  data  access  specification  judgments  that  apply  to 
the  antecedent  of  a  rule,  it  may  be  useful  to  recall  them.  Section  5.2  mentioned  the  following  relations,  where  we  have  listed 
them  in  inverse  order  of  their  introduction,  so  that  whenever  a  judgment  J\  depends  on  judgment  J2,  Ji  is  always  listed  after 
J2  (we  do  not  have  mutually  recursive  judgments): 


r; 

r; 

=►  r; 

A 

=►  r; 


A 

IP-, 

k  » 

A' 

A 

ipa 

k  » 

A' 

A 

IHa 

t  » 

A' 

> 

e  >  A' 

A 

Ihi 

Ihs  >  t^>  A' 

Given  knowledge  A,  principal  A  can  decipher  a  message 
encrypted  with  shared  key  k  in  context  T 

Given  knowledge  A,  principal  A  can  decipher  a  message 
encrypted  with  public  key  k  in  context  T 

Given  knowledge  A  and  terms  t,  principal  A  can  knows  A '  in  context  T 
Merging  context  knowledge  A  and  elementary  term  tuple  e  yields  A' 

Given  knowledge  A,  predicate  sequence  Ihs  and  terms  t, 
principal  A  can  knows  A'  in  context  T 


[p.|23) 

tP-E) 

[p-EJ 

[p.@ 

[p-ED 


Clearly,  we  need  to  prove  the  decidability  of  each  and  every  one  of  them.  Rather  than  subjugating  the  reader  to  this  long  and 
tedious  process,  we  pick  the  few  key  judgments  marked  with  an  arrow  (=>)  on  their  left  and  only  hint  to  the  required  results 
for  the  judgments  they  depend  on  (listed  above  them). 


Property  5.1 

Let  T  be  a  typing  context,  A  and  A'  knowledge  contexts,  A  a  principal  name  ,  and  t  a  multiset  of  terms.  It  is  decidable 
whether  the  judgment  T;  A  lbA  t  A'  holds.  Moreover,  for  any  choice  ofT,  A,  A  and  t,  there  are  finitely  many  knowledge 
contexts  A'  for  which  this  judgment  holds. 
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Proof:  Since  the  rules  that  implement  this  judgment  make  use  of  the  decryption  judgments  for  shared  and  public  keys,  we 
shall  first  discuss  the  analogous  property  concerning  them.  Let  us  consider  the  former,  ‘T;  A  k  2>  A'”.  In  our  language, 
this  judgment  is  realized  by  exactly  three  inference  rules,  none  of  which  has  premises  (see  Section  5.2.3|l.  This  makes  it 
clearly  decidable.  Moreover,  depending  on  which  rule  is  used  (assuming  one  is  applicable),  the  output  knowledge  context 
A'  will  either  be  identical  to  A  (in  rule  kac_ss),  or  result  from  adding  k  to  it  (in  rules  kac_sul  and  kac_su2):  there  are 
exactly  two  options.  It  is  indeed  possible,  although  probably  not  useful,  to  add  a  key  that  is  already  in  the  knowledge  context; 
therefore  these  two  rule  sets  are  not  exclusive.  A  similar  argument  applies  to  the  public  key  decryption  judgment.  Observe 
that  this  part  of  the  proof  is  language  dependent. 

We  now  turn  to  the  judgment ‘T;  A  h/;,  t  >  A'”,  which  is  implemented  by  the  six  rules  given  in  Section  : 


5.2.2 


Which 

one  to  use  is  determined  by  t,.  Several  may  be  applicable  at  any  instant,  but  the  possible  instantiations  is  limited  by  the  number 
of  elements  of  t,  which  is  finite.  Therefore,  in  order  to  prove  our  decidability  result,  we  only  have  to  show  that  no  branch  of 
the  derivation  tree  obtained  by  chaining  these  rules  can  be  infinite,  no  matter  which  instantiation  is  chosen.  In  order  to  do  so, 
observe  that  the  premises  of  the  rules  in  Section  5.2.2  either  call  the  decryption  judgment  for  keys,  that  we  have  just  proved 
decidable,  or  invoke  our  judgment  recursively  on  a  multiset  “smaller”  than  t.  Here  the  size  of  t  is  computed  by  counting  the 
number  of  constructors  and  elementary  terms  that  appear  in  it.  Since  the  size  of  t  cannot  decrease  ad  infinitum,  the  derivation 
tree  must  be  finite.  Therefore  the  above  judgment  is  decidable. 


As  for  the  number  of  possible  output  knowledge  contexts,  observe  that  A'  is  set  to  A  when  all  terms  t  have  been  processed 
by  rule  tac  dot.  Therefore,  we  simply  need  to  track  how  the  input  knowledge  is  modified  when  moving  from  the  conclusion 
to  the  premises  of  a  rule.  Rules  tac  ske  and  t  ac  pke  invoke  the  decryption  key  judgment;  we  saw  that  each  encryption 
operation  in  t  can  double  the  number  of  possible  output  contexts.  Since  rules  tac_kn  and  tac.ukn  are  not  exclusive,  each 
piece  of  elementary  information  in  t  can  also  double  this  number.  In  any  case,  since  t  is  finite  in  size,  only  finitely  many 
knowledge  contexts  can  be  produced.  □ 


We  now  turn  to  the  left-hand  side  as  a  whole  and  show  that  the  associated  data  access  specification  judgment  is  decidable. 
We  have  the  following  property: 


Property  5.2 

Let  r  be  a  typing  context,  A  and  A'  knowledge  contexts,  A  a  principal  name  ,  Ihs  the  left-hand  side  of  a  rule,  and  t  a 
multiset  of  terms.  It  is  decidable  whether  the  judgment  T;  A  Ihs  >  f  >  A'  holds.  Moreover,  for  any  choice  ofT,  A,  A, 
Ihs  and  t,  there  are  finitely  many  knowledge  contexts  A1  for  which  this  judgment  holds. 


Proof:  The  four  rules  implementing  this  judgment  are  displayed  in  Section|5.2.1  They  rely  on  the  term  multiset  validation 
judgment,  for  which  we  have  just  proved  an  analogous  property,  and  on  the  knowledge  merge  judgment  “A  >  e  >  A'”. 
Arguments  akin  to  those  used  for  Property  show  that  this  latter  relation  is  decidable  and  yields  finitely  many  output 
knowledge  contexts.  Armed  with  these  results,  we  observe  that  the  number  of  possible  instantiations  of  ‘T;  A  K,  Ihs  > 
t  A'”  is  determined  by  Ihs.  Moreover,  this  same  value  also  limits  the  number  of  possible  consecutive  invocations  of  this 
judgment.  Therefore,  it  is  decidable.  The  output  knowledge  counting  argument  proceeds  as  in  Property|5.1|  □ 


This  conclude  our  investigation  of  the  decidability  results  for  the  left-hand  side  of  a  rule.  Observe  that,  assuming  all 
other  parameters  fixed,  the  number  of  output  knowledge  contexts  is  exponential  in  the  number  of  constants  and  variables  we 
are  starting  from.  At  most  one  of  these  contexts  will  satisfy  the  analogous  relation  for  the  right-hand  side  of  a  rule.  They 
will  however  be  identical  up  to  duplication  of  data,  a  fact  that  can  be  used  to  obtain  a  deterministic  data  access  specification 
verification  procedure  for  the  antecedent.  It  should  however  be  observed  that  the  winning  knowledge  context  will  generally 
be  the  one  with  minimum  redundancy  when  analyzing  well-written  specifications. 
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5.5.2  Deciding  the  Right-Hand  Side  Judgments 

We  move  now  to  the  right-hand  side  of  a  rule.  The  judgments  we  will  be  concerned  about,  collected  in  inverse  dependency 


order  from  Section [531  are: 

T  s->A  e  Principal  A  can  access  atomic  information  e  in  context  T  [p.|26| 

r;Ah->A  t  Given  knowledge  A,  principal  A  can  construct  term  t  [p.|26| 

r;Ah->A  t  Given  knowledge  A,  principal  A  can  construct  term  tuple  t  [p.|26| 

=>  r;Ah->A  Ihs  Predicate  sequence  Ihs  is  constructible  from  knowledge  A  for  principal  A  [p.|25| 

=£>  T;A  lhA  rhs  Right-hand  side  rhs  implements  valid  data  access  specification  for  principal  A  [p.|25| 

in  context  T  given  knowledge  A 


Again  we  will  limit  our  statements  and  proofs  to  the  judgments  marked  with  an  arrow.  We  start  with  the  construction  judgment 
for  network  and  memory  predicate  sequences. 


Property  5.3 

Let  T  be  a  typing  context,  A  a  knowledge  set,  A  a  principal  name,  and  Ihs  a  sequence  of  network  and  memory  predicates. 
It  is  decidable  whether  the  judgment  T ;  A  S->A  Ihs  holds. 


Proof:  The  mles  implementing  this  judgment  in  Section  [53|dcpcnd  on  the  construction  judgments  for  terms  and  term  tuples, 
which  in  turn  depends  on  the  accessibility  judgment  for  elementary  terms  ‘T  e”.  The  latter  is  clearly  decidable  in 
our  language  since  it  is  implemented  in  Section  5.3.3  by  five  rules  without  premises.  The  applicability  of  the  construction 
judgments  is  completely  determined  by  the  structure  of  their  rightmost  parameter.  Therefore  they  are  decidable.  As  for  the 
judgment  at  hand,  the  number  of  applicable  instantiations  of  the  rules  that  implement  it  is  determined  by  Ihs,  and  so  is  the 
number  of  consecutive  invocations  of  this  judgment.  Since  a  right-hand  side  always  contains  finitely  many  predicates,  this 
judgment  is  decidable.  □ 


We  now  turn  to  the  judgment  that  validates  data  access  specification  for  a  whole  right-hand  side.  We  have  the  following 
property: 

Property  5.4 

Let  T  be  a  typing  context,  A  a  knowledge  set,  A  a  principal  name  ,  and  rhs  the  right-hand  side  of  a  rule.  It  is  decidable 
whether  the  judgment  F :  A  l|-A  rhs  holds. 


Proof:  Given  the  above  result,  the  decidability  of ‘T ;  A  h4  rhs”  can  be  ascertained  by  inspecting  the  three  rules  that  define 
it  in  Section  5.3.1  It  is  easy  to  see  that  the  number  of  recursive  invocations  of  this  judgment  is  given  by  the  number  of  fresh 
data  declarations  “zte  :  r”,  plus  one.  Therefore,  this  judgment  is  decidable.  □ 


This  concludes  our  treatment  of  the  right-hand  side  of  a  protocol  rule. 


5.5.3  Deciding  Data  Access  Specification  for  Protocol  Theories 


We  will  now  put  together  the  results  obtained  in  Sections  5.5. 1  and  5.5.2  in  order  to  obtain  decidability  results  for  rules,  roles 
and  protocol  theories.  The  involved  judgments,  in  inverse  dependency  order,  are  the  following: 


=►  r  lbA  r 

r  ihA  P 

=>  E  lb  V 


Rule  r  implements  valid  data  access  specification  for  principal  A  in  context  T 

Rule  collection  p  implements  valid  data  access  specification  for  principal  A  in  context  T 

Protocol  theory  V  implements  valid  data  access  specification  in  signature  E 


[P-0 

[p-0 

[P-0 


We  will  show  this  property  for  the  two  judgments  marked  with  an  arrow,  and  only  hint  at  this  result  for  the  central  relation. 
Let  us  then  start  with  showing  that  the  data  access  specification  judgment  for  protocol  rules  is  decidable. 


31 


5  DATA  ACCESS  SPECIFICATION 


Property  5.5 

Let  E  be  a  signature,  A  a  principal  name,  and  r  a  rule.  It  is  decidable  whether  the  judgment  T  lbA  r  holds. 


Proof:  This  judgment  is  implemented  by  two  rules  (uac_all  and  uac.core)  displayed  at  the  end  of  Section  5.1  The  former 


is  unproblematic  since  a  rule  is  prefixed  with  finitely  many  universal  quantifiers.  The  latter  depends  on  the  data  access  spec¬ 
ification  judgments  for  the  antecedent  and  the  consequent  of  r.  We  have  shown  these  judgments  decidable  in  Properties  |5.2| 
and|5.4|  However,  the  knowledge  context  A  appears  only  in  the  premises  and  could  be  a  source  of  undecidability.  This  is  not 
the  case  as  Property  |5.2| showed  that  the  leftmost  premise  can  produced  only  a  finite  number  of  such  contexts.  □ 


We  can  now  show  that  data  access  specification  for  roles  and  protocol  theories  can  be  effectively  verified.  We  have  the 
following  property  in  the  latter  case: 

Property  5.6 

Let  E  be  a  signature  and  V  a  protocol  theory  over  E.  It  is  decidable  whether  the  judgment  E  lb  V  holds. 


Proof:  The  rules  implementing  this  judgment  rely  on  the  data  access  specification  relation  for  roles  ‘T  W~A  p”,  described  in 
Section  5.1  This  judgment  is  clearly  decidable  since  it  deterministically  recurses  over  the  finitely  many  rules  and  universal 


quantifications  that  constitute  p.  We  have  proved  that  data  access  specification  is  decidable  for  rules  in  Property  |5. 5 1 

This  result  allows  us  to  prove  the  decidability  of  data  access  specification  for  protocol  theories  using  a  similar  argument. 

□ 


5.5.4  Deciding  Data  Access  Specification  for  Active  Role  Sets 

We  now  extend  the  above  results  to  active  roles.  The  involve  judgments  are: 


(...) 

E  lb  R 


Active  role  set  R  implements  valid  data  access  specification  in  signature  E 


[sec.|5.4| 

[p-HD 


where  the  first  line  corresponds  to  the  variants  of  most  of  the  judgments  examined  so  far,  with  the  additional  rules  seen  in 


Section  5.4  to  deal  with  variables  instantiated  with  ground  terms.  The  decidability  proofs  for  these  variants  differs  from  the 
“originals”  above  by  the  fact  that  more  cases  need  to  be  considered.  Concretely,  these  rules  raise  the  number  of  possible 
output  knowledge  contexts  (when  one  is  present),  but  never  make  it  infinite. 

We  have  the  following  decidability  result  for  active  roles: 


Property  5.7 

Let  E  be  a  signature  and  R  an  active  role  set  over  E.  It  is  decidable  whether  the  judgment  E  lb  R  holds. 

Proof:  Given  the  above  discussion  on  the  decidability  of  the  judgment  variants  for  active  roles,  the  above  judgment  is  trivially 
valid  since  the  rules  that  implement  it  (given  in  Section  [5~4|>  simply  recurse  on  the  (finite)  number  of  active  roles  present  in 
R.  □ 


This  concludes  our  analysis  of  the  computability  properties  of  the  data  access  specification  judgments  discussed  in  this 
section. 


5.6  Changes 

No  notion  of  data  access  specification  was  present  in  our  earlier  versions  of  MSR  mmi  It  is  however  interesting  to  observe 
that  the  satisfaction  of  these  judgments  constrains  the  structure  of  admissible  protocol  theories  beyond  typing  (see  Section[4]) 
and  beyond  the  requirements  of  these  initial  versions. 
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1.  The  fact  that  the  arguments  of  a  role  state  predicate  should  be  elementary  terms  was  mostly  implicit  in  our  earlier  work. 

2.  Moreover,  the  requirement  that  the  arguments  of  occurrences  of  these  predicates  on  the  right-hand  side  of  a  rule  should 
mention  all  the  information  used  in  this  rule  was  only  verbally  specified. 

3.  Finally,  the  request  that  the  first  argument  of  a  role  state  predicate  be  a  principal  (the  role  owner)  was  made  in  l(30l 
and  lt3Tl.  but  not  in  previous  work. 


6  Protocol  Execution 


The  typing  and  data  access  specification  policies  defined  in  the  previous  sections  provide  ways  of  statically  checking  that 
the  MSR  specification  of  a  protocol  meets  well-understood  default  notions  of  adequacy.  More  complex  analyses  require  a 
description  of  how  a  protocol  evolves  at  run  time.  In  this  section,  we  will  define  such  an  execution  model  for  MSR ,  and 
study  how  it  interacts  with  typing  and  data  access  specification.  More  precisely,  we  will  first  complete  the  definition  of  the 
pervasive  notion  of  substitution  in  Section  6.1  Then,  we  will  present  the  basic  one-step  rule  application  and  its  sequential 
iteration  in  Section  [fv2]  In  Section  [63]  we  extend  this  notion  to  allow  concurrent  rule  firing.  In  Section  |6.4[  we  show  that 


execution  preserves  typing  and  in  Section  6.5  we  prove  a  similar  result  about  its  interaction  with  data  access  specification. 


We  conclude  in  Section  6.6  with  a  discussion  of  the  main  changes  with  respect  to  previous  versions  of  MSR. 


6.1  Substitutions 


In  this  section,  we  will  complete  the  presentation  of  the  syntax  and  interpretation  of  the  notion  of  substitution.  Given  a 
variable  x  and  an  object  O  that  may  mention  x  as  a  parameter,  we  denote  the  substitution  of  a  term  t  for  x  in  O  as  [t/x}0. 
As  far  as  the  execution  rules  are  concerned,  the  instantiating  term  t  will  always  be  ground,  and  therefore  the  implementation 
of  substitution  does  not  need  to  take  particular  provisions  aimed  at  avoiding  variable  capture  (i.e.  the  risk  that  a  free  variable 
in  t  may  accidentally  become  bound  in  ()).  The  parametric  objects  O  we  will  be  interested  in  are  other  terms  term  tuples 
t,  types  t,  tuple  types  r,  predicate  sequences  Ihs,  right-hand  sides  rhs,  rules  r,  and  rule  collections  p.  All  together,  we  will 
encounter  the  following  forms  of  substitution: 

\t/x\t'  [t/x]t  [t/x\T  [t/x\x  [t/x]lhs  [t/x\rhs  [t/x]r  [t/x]p 


Observe  that,  for  simplicity,  we  are  overloading  the  bracket  notation  to  denote  the  application  of  the  substitution  operation 
to  objects  belonging  to  different  syntactic  categories.  We  only  need  to  define  the  substitution  of  t  for  x  in  objects  that  may 
mention  x  as  a  free  variable.  This  is  why  we  do  not  include  protocol  theories,  states  and  active  roles  in  the  above  list. 


Our  definition  of  this  operation  is  relatively  standard,  but  some  aspects  deserve  comments.  For  the  sake  of  unity,  we  start 


by  redisplaying  the  definition  of  substitution  for  terms,  types  and  tuple  types  from  Section  3.1.3 


[t/x\r 

[t/x)T 

\t/x\t' 

[t/x]- 

[t/x](r^  x  t )  =  {\t/x\r)^  x  ([t/x\f) 

[t/x]  principal  =  principal 

[f/a;]nonce  =  nonce 

[£/x]shK  AB  =  shK  ([£ /x\A)  ([£ /x]B) 

[f/x]pubK  A  =  pubK  (\t/x\A) 

[f/a;]privK  k  =  privK  ([t/x]k) 

[t/x\  msg  =  msg 

[t/x\a  =  a 

r .  /  -i  it  if  y  =  x 

\t/x]y  =  <  J; 

L  '  J  \y  otherwise 

[t/x](t'1t'2)=  ([t/x}t[)([t/x}t'2) 

[t/x\{t’}k  =  {[t/x]?  }[t/x]k 

[t/xWlk  =  IWxfflw  *]* 

Observe  again  that,  while  dependent  tuple  types  are  universal  constructions,  the  defining  equalities  for  terms  and  types  are 
language-specific,  and  therefore  need  to  be  adapted  for  languages  more  elaborate  than  what  considered  in  this  document.  It 
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should  also  be  noticed  that  instantiation  is  concerned  with  the  syntactic  form  of  an  object:  in  particular,  a  substitution  should 
be  applied  to  the  encryption  key  of  an  encrypted  message,  even  though  the  key  itself  it  not  (typically)  transmitted. 
Substitution  for  term  tuples,  another  universal  construction,  is  defined  by  the  following  two  simple  equalities: 


[t/x]t 

[t/x\- 

\t/x\{t',  t)  =  {[t/x]t'),  ([t/x]t] 


We  next  turn  to  the  predicate  sequences,  intended  to  model  the  left-hand  side  of  a  protocol  rule,  and  to  rule  consequents. 
In  the  former  case,  the  operation  reduces  to  applying  the  substitution  to  the  arguments  of  all  the  predicates  that  constitute 
the  sequence  Ihs.  Notice  in  particular  that  the  owner  A  of  a  memory  predicate  M  4(f)  is  itself  an  argument,  although  in  a 
special  position.  The  first  line  in  the  second  column  deals  with  consequents  that  are  simple  predicate  sequences.  Although 
it  looks  redundant,  we  should  remember  that  our  syntax  is  overloaded:  substitution  on  a  degenerate  consequent  reduces  to 
substitution  on  the  embedded  antecedent  (defined  in  the  column  on  the  left).  In  the  second  line  on  the  rightmost  column, 
we  rely  on  implicit  a-conversion  to  make  sure  that  the  bound  variable  will  have  a  different  name  than  the  variable  x  being 
instantiated.  Observe  how  the  substitution  is  pushed  inside  the  type  declaration. 


[t/x\lhs 

[■ t/x\rhs 

[t/x\ 

[t/x\(lhs,  N(f))  =  ([t/x\lhs),  N([f/a;]f) 

[t/x](lhs,  L(e))  =  )[t/x\lhs),  L([t/x]e) 

[t/x\(lhs,  M A(t))  =  ([ t/x\lhs ),  M[t/x]A([t/x]t) 

[t/x]lhs  =  [t/x]lhs 

[t/x](3y  :  t.  rhs)  =  3 y  :  ([f/a;]r).  ( [t/x\rhs ) 

Last,  we  turn  to  rules  and  rule  collections.  Again,  we  take  advantage  of  a-conversion  to  avoid  making  special  provision  in 
case  the  bound  variable  happens  to  be  called  x.  These  definitions  systematically  push  the  substitution  inside  all  the  syntactic 
elements  of  a  rule  (collection). 


[t/x\r 

[t/x\p 

[t/x](lhs  — »  rhs)  =  ([t/x]lhs)  — >  ([ t/x\rhs ) 

[t/x\(Vy  :  r.r)  =  Vy  :  ([t/x}r).  ([t/x]r) 

[t./x]- 

[t/x\(3L  :  t.  p)  =  3 L:  ([t /x\t).  ([ t/x\p ) 

[t/x\{r,  p)  =  ([t/x]r),  ([ t/x\p ) 

Besides  term  variables,  rule  collections  contain  a  second  kind  of  parameter,  namely  role  state  predicate  symbols,  that  we 
have  denoted  with  the  letter  L,  variously  decorated.  During  execution,  we  will  need  to  instantiate  them  to  constants  of  the 
form  L/,  where  l  is  a  label.  We  extend  our  syntax  and  write  [L i/L]0  for  the  substitution  of  variable  L  with  L/  in  object  (). 
This  operation  applies  to  left-hand  sides  Ihs,  consequents  rhs,  rules  r,  and  rule  collections  p : 

[L  i/L\lhs  [I h/L\rhs  [h/L]r  [U/L]p 

It  should  be  observed  that  although  L  stands  for  a  predicate  symbol,  it  never  needs  to  be  instantiated  to  anything  more  complex 
than  a  constant.  The  higher-orderness  of  our  notation  is  only  apparent. 

The  implementation  of  this  operation  is  similar  to  term  substitution.  We  have  the  following  definition  in  the  case  of  rule 
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antecedent  and  rule  consequents,  respectively.  Clearly  this  substitution  does  not  need  to  be  pushed  into  terms. 


[L  i/L\lhs 

[L  i/L\rhs 

[U/L]- 

[Li /L\(lhs,  N(t))  =  ([Li /L\lhs),  N(f) 

[L(/r](//is,  L>&)  =  {<[[$][$; 

[Li /L](lhs,  M A(t))  =  ([Li /L]lhs),  M A(t) 

[h/L\lhs  =  [1 U/L\Uis 

[L//L](3at  :  r.  rhs)  =  3 x  :  t.  ([L;/L]?’/is) 

The  application  of  a  role  state  predicate  substitution  to  rule  and  a  rule  collection  is  given  below.  Observe  that  again  we  rely 
on  implicit  o-conversion  when  pushing  the  substitution  inside  the  right-hand  side  of  a  rule  collection. 


[L  i/L)r 

[L  i/L\p 

[Li /L\(lhs  — >  rhs)  =  ([L i/L\lhs)  — >  ([Li /L\rhs) 

[Li /L]  (Vat  :  r.  r)  =  Vat :  t.  ([U/L)r) 

[U/L]- 

[U/L](3L'  :  t.  p)  =  3L' :r.([U/L\p) 

[U/L](r,  p)  =  ([Li /L]r),  ([L, /L]p) 

This  concludes  the  definition  of  the  notion  of  substitution  that  will  be  needed  in  the  rules  modeling  the  execution  of  a 
protocol.  In  Sections  [6.4|and|63]  when  studying  how  execution  interacts  with  typing  and  data  access  specification,  we  will 
need  to  observe  the  effect  of  performing  a  substitution  relative  to  the  typing  and/or  knowledge  contexts  of  a  judgment.  For 
this  reason,  we  need  to  define  an  instantiation  operation  for  these  objects  as  well.  Given  a  typing  context  T  and  a  knowledge 
context  A,  we  will  encounter  the  notation: 

[f/at]T  \t/x\  A 

The  defining  equalities  are  given  in  the  table  below.  Observe  that  in  the  case  of  a  typing  context,  this  operation  applies  only  to 
the  type  part  of  a  declaration,  and  not  to  the  introduced  variable:  we  will  never  be  in  a  position  where  x  should  be  substituted 
in  a  context  containing  the  declaration  x  :  r.  Substitution  over  a  typing  context  is  given  on  the  right  column.  Its  last  line  is 
concerned  with  the  extended  notion  of  knowledge  needed  to  handle  active  roles:  it  should  be  remembered  that  t'  cannot  be 
but  a  ground  term. 


[t/x]T 

[t/x\A 

[t/ at]X  =  X 

[t/x](T,y  :  t )  =  ([t/x]T),y  :  ([ t/x\r ) 

[t/x](T,L  :  f)  =  ([ t/x]T),L  :  ([ t/x]f ) 

[t/x\-  =  ■ 

[t/x\{A,a)  =  {[t/x] A),  a 

\t/x\(A  v)  =  / ([*/*JA)»  t  *y  =  z 
'  ^  ^  {([t/xjA),  y  otherwise 

\t/x](A,t')  =  ([//at] A),  t' 

6.2  Sequential  Firing 

Execution  is  concerned  with  the  use  of  a  protocol  theory  to  move  from  a  situation  described  by  a  state  S  to  another  situation 
modeled  by  a  state  S' .  In  this  section,  we  will  introduce  judgments  and  rules  describing  the  atomic  execution  steps  that  lead 
from  S  to  S'.  We  will  then  show  how  they  can  be  chained  to  perform  multi-rule  sequential  applications. 

Referring  to  the  situation  that  the  execution  of  a  protocol  has  reached  by  means  of  a  state  is  an  oversimplification.  Two 
more  ingredients  are  required:  first  we  need  to  know  which  roles  can  be  used  in  order  to  continue  the  execution,  at  which  point 
they  were  stopped,  and  how  they  were  instantiated.  This  calls  for  an  active  role  set.  Second,  it  is  very  convenient  to  carry 
around  a  list  of  the  constants  in  use  in  a  signature:  this  allows  us  in  particular  to  verify  that  instantiations  are  well-formed 
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and  well-typed.  Situations  are  then  formally  defined  as  a  triple  consisting  of  a  state  S,  an  active  role  set  R  and  a  signature  X. 
Such  triples  are  called  snapshots ,  and  denoted  as  in  the  following  grammatical  production: 

Snapshot:  C  ::=  [S]  ^ 


We  shall  observe  that  no  element  in  a  snapshot  contains  free  variables:  X  is  clearly  ground,  and  so  is  the  state  S;  the  active 
role  set  R  will  generally  contain  bound  variables,  but  execution  will  always  instantiate  them  to  ground  terms. 

Given  a  protocol  V ,  we  describe  the  fact  that  execution  transforms  a  snapshot  C  into  another  snapshot  C  in  one  step  by 
means  of  the  following  judgment,  where  we  have  expanded  the  definition  of  C  and  C'  to  familiarize  the  reader: 

V  >  [S']  §  — ►  [S']  y.,  One-step  sequential  firing 


This  judgment  is  implemented  by  the  next  six  rules  that  fall  into  three  classes.  We  should  be  able  to:  first,  make  a  role  from 
V  available  for  execution;  second,  perform  instantiations  and  apply  a  rule;  and  third,  skip  rules  (more  on  this  later). 


We  first  examine  how  to  extend  the  current  active  role  set  R  with  a  role  taken  from  the  protocol  specification  V .  As 

,A  and  generic  roles  pJ  A .  This  yields  the  following  two  rules. 


defined  in  Section 
respectively: 


4.3 


V  can  contain  both  anchored  roles  p 


arole 


IS}* 


[^] 


R,p 

s 


X  h  A:  principal 


(v,PVA)>  [S]£ 


[5]  fl,([A/A]p)A 


sex_grole 


Anchored  roles  can  simply  be  copied  to  the  current  active  role  sets  since  their  syntax  meets  the  requirements  for  active  roles. 
In  order  to  make  a  generic  role  available  for  execution,  we  must  assign  it  an  owner.  The  premise  of  rule  sex_grole  selects  a 
principal  name  A  from  the  current  signature  X  and  instantiates  p  with  it.  Observe  that  this  premise  relies  the  typing  judgment 
to  make  sure  that  A  is  defined  and  that  it  actually  stands  for  a  principal  name.  We  could  have  alternatively  looked  it  up  in  X 
directly. 

Once  a  role  has  been  activated  by  either  of  the  above  rules,  chances  are  that  it  contains  role  state  predicate  parameter 
declarations  that  require  to  be  instantiated  with  actual  constants  before  any  of  the  embedded  rules  can  be  applied.  This 
situation,  characterized  by  the  fact  that  the  active  role  under  examination  has  the  form  (VL  :  t.  p)A,  is  implemented  by  the 
following  rule,  which  generates  a  fresh  constant  L/,  adds  a  declaration  for  it  in  the  current  signature  X,  and  replaces  every 
occurrence  of  L  in  p  with  it.  Notice  that  L(  shall  be  a  new  symbol  that  appears  nowhere  in  the  current  snapshot  (in  particular 
it  should  not  occur  in  X). 

- sex_rsp 

V>  -+ 

Processing  a  role  state  predicate  parameter  declaration  prefix  may  have  the  effect  of  exposing  a  protocol  rule  r.  At  this 
point,  r  can  participate  in  an  atomic  execution  step  in  two  ways:  we  can  either  skip  it  (discuss  below),  or  we  can  apply  it 
to  the  current  snapshot  to  obtain  a  new  configuration.  The  latter  option  is  implemented  by  the  inference  rule  below,  which 
makes  use  of  the  rule  application  judgment  “r  c>  [5]  s  [S"]  s,”  to  construct  the  state  S'  and  the  signature  X'  resulting  from 
the  application.  We  will  describe  this  judgment  shortly.  The  changes  to  the  active  role  set  are  limited  to  discarding  the  used 
rule  r. 

r  >  [5]  s  [S"]  s, 

- sex_rule 

V>  [S]£l(r’p)A  — ►  [S']£;(p)A 

Only  the  simplest  of  security  protocols  specify  a  purely  linear  sequence  of  actions.  More  complex  systems  allow  various 
forms  of  branching  or  even  more  complex  layouts.  In  a  protocol  theory,  the  control  structure  is  mostly  realized  by  the  role 
state  predicates  appearing  in  a  role.  Branching  can  be  modeled  by  having  two  rules  share  the  same  role  state  predicate 
parameter  in  their  left-hand  side.  Roles,  on  the  other  hand,  are  defined  as  a  linear  collection  of  rules.  Therefore,  in  order  to 
access  alternative  role  continuations,  we  may  need  to  skip  a  rule,  i.e.  discard  it  and  continue  with  the  rest  of  the  specification. 
The  following  two  execution  rules  implement  this  scenario: 


V> 


|s]*.(-,p)' 


-  sex_skp 


v>  [5] 


r,(Y 

S 


- sex_dot 

[s\i 
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The  inference  on  the  left  skips  a  protocol  rule.  Rule  sex_dot  does  some  housekeeping  by  throwing  away  active  roles  that 
have  been  completely  executed. 

When  successful,  the  application  of  a  rule  r  to  a  state  S  in  the  signature  X  produces  an  updated  state  S'  defined  in  the 
extended  signature  S'.  This  operation  is  defined  by  the  following  judgment: 

r  >  [S]E  >  [S']  E,  Rule  application 

It  is  implemented  by  two  rules  that  discriminate  on  the  structure  of  a  protocol  rule. 

In  order  to  apply  a  rule  to  the  current  state,  we  first  need  to  appropriately  instantiate  the  universal  variables  that  may  appear 
in  it.  Our  next  execution  rule  will  therefore  examine  rules  of  the  form  (Vx  :  r.  r).  It  instantiates  x  to  some  well-formed  term 
t  of  type  t  in  the  current  signature: 

X  h  t  :  t  [t/x\r  >  [51]  E  [5']  E/ 

- sex_all 

(Vx  :  r.  r)  >  [5]  E  >  [S']  E, 

Again,  we  make  use  of  the  typing  judgment  to  ascertain  that  t  has  type  r  in  X.  The  attentive  reader  may  be  concerned  by 
the  fact  that  the  construction  of  the  instantiating  term  t  is  not  guided  by  the  contents  of  the  state  S.  This  is  a  very  legitimate 
observation:  the  rule  above  provides  an  idealized  model  of  the  execution  rather  than  the  basis  for  the  implementation  of 
an  actual  simulator.  We  may  want  to  think  of  the  premise  of  this  rule  as  a  non-deterministic  oracle  that  will  construct  the 
“right”  term  to  successfully  continue  the  execution.  An  operational  model  suited  for  implementation  is  the  subject  of  current 
research. 

We  now  consider  execution  steps  resulting  from  the  application  of  a  fully  instantiated  rule  of  the  form  “Ihs  — >  rhs ”,  The 
antecedent  Ihs  must  be  ground  and  therefore  it  has  the  structure  of  a  legal  state.  This  rules  identifies  Ihs  in  the  current  state 
and  replaces  it  with  a  substate  Ihs1  derived  from  the  consequent  rhs.  This  latter  operation  is  performed  in  the  premise  of  this 
rule  by  the  right-hand  side  instantiation  judgment  “(rhs)z  ( Ihs ')■£'”  that  will  be  discussed  shortly. 

(rhs)z  »  (Ihs')s' 

- sex_core 

( Ihs  — t  rhs)  >  [S’,  Ihs }  E  [5,  Ihs1]  E, 

The  right-hand  side  instantiation  judgment  used  in  the  premise  of  rule  sex_core  generates  a  ground  predicate  sequence 
Ihs  from  the  consequent  rhs  of  a  fully  instantiated  rule  r  from  an  active  role  (r,  p)A.  The  resulting  changes  to  the  current 
signature  X  are  reflected  in  the  updated  signature  X'.  This  judgment  is  defined  as  follows: 

(rhs)s  (Zfts)s'  Right-hand  side  instantiation 

It  is  implemented  by  the  following  two  rules,  which  instantiate  the  existentially  quantified  variables  possibly  wrapped  around 
the  core  of  rhs.  If  this  parameter  is  already  a  predicate  sequence,  we  simply  return  it,  without  making  any  change  to  the 
signature  X: 

- sex_seq 

{lhs)s  >  (lhs)s 

The  instantiation  of  an  existentially  quantified  term  variable  x  is  handled  in  rule  sex  nnc  below.  We  generate  a  fresh  term 
constant  a  of  the  appropriate  type,  records  this  fact  in  the  signature,  and  replaces  every  occurrence  of  x  with  a  before  exam¬ 
ining  the  body  of  rhs. 

([a/x]rhs)(£,a-.T)  >  (lhs)v> 

-  sex_nnc 

(3x  :  r.  rhs)?,  »  ( Ihs )vy 

Observe  that,  in  this  rule,  the  generated  constants  should  not  appear  anywhere  in  the  current  signature  X  (and  therefore  in  the 
left-hand  side  of  the  judgment):  this  object  is  new. 

We  conclude  this  section  by  providing  a  judgment  and  the  associated  inference  rules  that  allow  us  to  chain  the  atomic 
steps  presented  above  into  multi-step  sequential  firings.  This  allows  simulating  executions  consisting  of  any  number  of  basic 
steps  between  two  snapshots  of  interest.  We  have  the  following  judgment: 

V  >  C  — >*  C'  Multi-step  sequential  firing 
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The  following  rules  define  this  judgment  as  the  reflexive  and  transitive  closure  of  the  atomic  step  relation  discussed  above. 

V  >  C  — >  C'  V>  C'  — >*  C" 

- sex_itO  - sex_itn 

Vi >  C  — >*  C  V\ >  c  — >*  c" 

The  following  simple  lemma  will  turn  useful  in  the  sequel. 

Lemma  6.1  ( Chaining  of  Sequential  Firings ) 

If  V>  C  — >*  C'  and  V>  C'  — E  C",  then  Vi >  C  — >*  C". 

Proof:  By  induction  on  the  structure  of  a  derivation  for  “V  >  C  — >*  C” .  □ 


6.3  Parallel  Firing 

Multi-step  sequential  firing  simulates  the  execution  of  a  protocol  one  rule  at  a  time.  However,  even  the  simplest  of  protocols 
are  inherently  concurrent  systems  and  allow  independent  roles  to  be  executing  at  the  same  time.  Although  interleaving 
permits  reducing  such  a  behavior  to  the  sequential  case,  it  is  interesting  to  provide  a  direct  specification  of  this  model.  In  this 
section,  we  will  first  discuss  executions  that  can  be  obtained  as  the  parallel  composition  of  one-step  sequential  firings,  and 
then  generalize  it  to  multi-step  parallel  firing.  We  conclude  by  establishing  a  formal  relationship  between  the  sequential  and 
parallel  models  of  execution. 

We  will  rely  on  the  following  judgment  to  express  the  fact  that  snapshot  C  is  obtained  from  C  by  executing  zero  or  more 
atomic  steps  in  parallel: 

V  t>  C  =>  C  One-step  parallel  firing 

The  two  rules  below  implement  this  judgment.  The  leftmost  inference  captures  the  degenerate  situation  where  no  basic  step 
is  applied:  the  current  snapshot  is  returned  as  output.  The  rule  on  the  right  expresses  parallel  execution:  intuitively,  we  want 
to  partition  the  current  state  description  into  partial  snapshots,  independently  apply  one  basic  step  to  each,  and  then  merge 
the  results  together  to  obtain  the  output  snapshot. 

il  (E.sj)  ^  >  [^2]  e2  =>  [£2]  (S,S'2) 

-  pex_par 

(Jti,fl2)  _ .  rnr 

Technically,  rule  pex  par  operates  as  follows:  it  splits  the  current  state  in  two  parts  S 1  and  S2,  and  similarly  partitions  the 
active  role  set  into  R\  and  R2.  The  left  premise  applies  one  atomic  execution  step  to  the  partial  snapshot  [Si]  ,  producing 

r' 

[Sj  ]  ^  >j; ,  as  a  result,  where  E]  is  the  amount  by  which  the  current  signature  E  has  been  extended  during  this  step.  Rather 
than  having  an  unbounded  number  of  premises,  we  call  our  parallel  firing  judgment  recursively  in  the  rightmost  premise:  in 
zero  or  more  atomic  steps,  we  transform  the  remainder  of  the  initial  snapshot,  [S2]  ^  ,  into  [S£]  (  f  s,  ^  where  again  Ej  is  the 
resulting  signature  extension.  The  overall  output  snapshot  is  constructed  by  taking  the  multiset  union  of  the  returned  states 
S[  and  S'2,  juxtaposing  the  output  active  role  sets  R[  and  R'2 ,  and  combining  the  resulting  signatures  (E,  Ej)  and  (E,  E2) 
into  (E,Ei,E'2). 

It  should  be  noted  that  the  input  snapshots  to  the  premises  of  rule  pex_par  have  no  state  element  or  active  role  in  common: 
they  are  independent.  They  both  rely  on  the  same  signature  E  since  unrelated  state  objects  and  active  roles  may  in  general 
refer  to  the  same  constants.  The  application  of  a  basic  step  can  at  most  extend  the  initial  signature  E  (see  Lemma |6.2| b e I o w ) , 
which  justifies  expressing  the  signature  output  by  the  two  premises  as  (E,  Ej),  for  i  =  1,2.  We  can  always  choose  the  newly 
generated  names  so  that  Ej  and  E2  do  not  declare  the  same  constant:  under  this  assumption,  (E,  E1;  E2)  is  structurally  a 
well-formed  signature. 

The  last  judgment  we  will  consider  iterates  one-step  parallel  firings.  It  is  expressed  as  follows: 

V  >  C  =>*  C  Multi-step  parallel  firing 


Vt>  [£ilfll 


5lJ  E 


[S 


Vi>  c 


c 


pex_id 


Vi>  [Si,S2] 


38 


6  PROTOCOL  EXECUTION 


Similarly  to  multi-step  sequential  firing,  it  is  obtained  by  taking  the  reflexive  and  transitive  closure  of  its  one-step  restriction: 


V>  C 


c 


■  pex_itO 


v>  c 


C'  V  >  C' 


v>  c 


C" 


C" 

- pex_itn 


We  conclude  this  section  with  a  few  results  concerning  execution,  ultimately  with  the  admissibility  of  parallel  firing  rules. 


We  will  investigate  the  relationship  between  execution  and  the  typing  and  data  access  specification  rules  in  Sections  6.4 
and!6.5l 


We  start  with  a  lemma  that  asserts  that,  as  execution  proceeds,  the  initial  signature  can  only  be  extended.  As  a  space 
saver,  we  write  V  >  C  — >{*>  C  to  indicate  that  we  are  considering  the  one-step  ('P  t>  C  — ►  C')  and  the  multi-step 
(V  >  C  — >*  C')  versions  of  the  sequential  firing  judgment  at  once.  We  adopt  a  similar  convention  for  the  parallel  firing 
judgments. 


Lemma  6.2  ( Signature  Extension) 

Let  X  and  X'  be  signatures,  rhs  the  right-hand  side  of  a  rule,  Ihs  a  predicate  sequence,  r  a  rule,  S  and  S'  states,  V  a 
protocol  theory,  and  R  and  R'  active  role  sets. 

1.  If  (rhs)s  (Ihs)s',  then  S'  =  (X,X77)  for  some  signature  X77 . 

2.  If  r>  [S']  £  [S']  E,,  then  X7  =  (X,  X")  for  some  signature  X" . 

3.  If  V  >  [S]  §  — [S7]  f,,  then  X7  =  (X,X7/)  for  some  signature  X7/ . 

Proof:  The  proof  proceeds  by  induction  on  the  structure  of  a  derivation  of  the  judgments  in  each  of  the  three  parts  of  this 
lemma.  These  results  are  not  mutually  recursive  and  shall  be  proved  in  the  given  order.  We  present  only  a  sketch  of  this  very 
simple  proof,  reserving  a  detailed  illustration  of  the  technique  used  for  more  substantial  examples  in  the  sequel. 

The  first  result  (1)  is  immediate  for  rule  sex_seq  and  follows  by  an  appeal  to  the  induction  hypothesis  for  rule  sex_nnc. 
The  second  point  in  this  lemma  (2)  relies  on  (1)  for  rule  sex  core  and  the  induction  hypothesis  for  rule  sex  all.  The  last 
result  (3),  is  immediate  for  rules  sex  arolc,  sex  grole,  sex  rsp,  sex  skp,  sex  dot,  and  sexJtO.  It  relies  on  (1)  for  rule 
sex_rule  and  follows  by  induction  for  rule  sex_itn.  □ 


We  now  turn  to  proving  that  parallel  firing  can  be  emulated  by  sequential  execution.  The  proof  of  this  property  relies  on 
a  number  of  simple  lemmas,  the  first  of  which,  given  below,  states  that  term  typing  is  invariant  with  respect  to  weakening: 
if  a  term  is  typable  in  a  signature,  it  remains  typable  when  considering  additional  declarations.  We  will  extend  this  result  in 
Section  [6741 

Lemma  6.3  ( Weakening  Term  Typing) 

Let  (X,X77)  be  a  signature,  t  a  term  and  r  a  type.  If  (X,X7/)  h  t  :  r,  then  (X,X7,X77)  h  f  :r  for  any  signature  X7. 

Proof:  The  proof  proceeds  by  induction  on  the  structure  of  a  derivation  T  of  the  given  judgment.  It  is  unconditionally  valid 
when  the  last  (and  only)  rule  of  T  is  mpt_a.  It  relies  on  immediate  appeals  to  the  induction  hypothesis  in  the  other  cases 
(rules  mtp  ss,  mtp  cnc,  mtp  ske  and  mtp  pkc).  □ 


We  now  come  to  the  central  lemma  in  the  proof  of  the  admissibility  of  the  rules  for  parallel  firing.  It  asserts  that  not  only 
signatures,  but  also  states  and  active  role  sets  can  be  weakened  in  an  execution  judgment,  without  influencing  its  derivability. 
The  first  result  in  this  lemma  is  needed  in  the  proof  of  the  remaining  two. 

Lemma  6.4  ( Weakening  Execution) 

Let  X  and  X77  be  signatures,  rhs  the  right-hand  side  of  a  rule,  Uis  a  predicate  sequence,  r  a  rule,  V  be  a  protocol  theory, 
S  and  S"  states,  and  R  and  R"  active  role  sets.  For  any  signature  X7,  state  S'  and  active  role  set  R', 
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1.  if  (rhs)s  >  (ZAs)e, s",  t/ten  (r/is)s,E'  >  (Jfts) e,e',e". 

2.  if  r  >  [5]  E  [5"]  EjE„,  r  >  [5]  E|E,  [5"]  S;E/)K//- 

3.  if  r>  [S]g  — ►«  [S"]gE„,  f/zen  P  >  [S,S']£§'  — ►<*)  [5',  S"1 


4  if  V>  [S]£ 


I  E,E" 
J"1  R" 


►w  [5"]g;E,„  r/!e»  [5,5']^; 


E,£',E'" 

[S",  S'"]  E  E/  E/, 


(*)  \  Qf  Q/r\  R' ,R‘ 


Proof:  We  proceed  by  induction  on  the  structure  of  a  derivation  for  the  antecedent  of  each  result.  In  (1),  the  property 
is  immediate  for  rule  sox  seq  and  is  obtained  by  application  of  the  induction  hypothesis  for  rule  sex  imc.  We  proceed 
similarly  in  the  case  of  (2),  except  that  we  make  use  of  f  1 )  for  rule  sex_rule  and  of  Lemma[63]for  rule  sex_all.  The  treatment 


of  (3)  is  again  similar,  with  the  use  of  (2)  for  rule  sex_rule  and  of  Lemma  6.3  for  rules  sex_grole.  Finally,  (4)  is  again  treated 


along  the  same  lines,  but  it  should  be  noted  that  the  state  and  active  role  sets  extensions  (S'  and  R'  respectively)  can  be  split 
arbitrarily  in  the  premises  of  rule  pox  par.  □ 


We  can  now  prove  our  admissibility  result:  an  arbitrary  parallel  execution  can  be  simulated  by  sequential  firing  sequences. 
Unsurprisingly,  the  reverse  of  this  property  holds  as  well:  any  sequential  execution  can  be  lifted  to  a  (degenerate)  form  of 
parallel  firing. 


Theorem  6.5  ( Admissibility  of  Parallel  Execution) 

Let  V  be  a  protocol  theory,  and  C  and  C  two  snapshots.  If  V  >  C 
V  >  C  — C',  then  V  >  C  =>W  C. 


C,  then  Vt>  C 


C.  Viceversa,  if 


Proof:  In  its  forward  direction,  the  proof  of  this  result  proceeds  by  induction  on  the  structure  of  a  given  derivation  £  of 
the  judgment  V  >  C  C'.  We  will  examine  the  one-step  case  in  detail,  but  omit  the  simple  proof  of  its  multi-step 

extension.  We  proceed  by  cases  on  the  last  rule  of  £\  for  single-step  parallel  firing,  only  rules  pex_id  and  pex_par  need  to 
be  considered. 


pex_id 


£  = 


C 


-  pex_id 


v>  c 

with  C’  =  C. 

The  result  is  obtained  by  instantiating  rule  sex_itO  with  the  same  parameters. 


£i  £2 

V>  [S,]*1  — >  [S[]*  V>[S2}^  = 


f of]  R2 

L°2J  s.s' 


pex_par 


£  = 


V>  [ft,  ft 


Ri  ,R2 


r o'  o']  R11R2 
°2j 


with  c  =  [ft,  ft]  s1,i?2  and  C'  =  [ft,  ft]  E^E, . 


The  proof  of  this  case  consists  of  the  following  transformations,  where  the  first  column  gives  a  name  to  the  derivation 
of  the  judgment  in  the  second  column: 


£'1  "T»  [SuS*]*"**  — ►  [ft.ftlg^ 


ft*  "  [ft]*2 


\  on  R'2 
L°2J  (S,S'2) 


by  the  Weakening  Lemma  6.4  2)  on  ft , 
by  induction  hypothesis  on  £■>, 


Cf  T?  \  Q'  Q  1  Rl  ;  R2  ,  r  of  of  1  Rl  ’R2 

C2  ■■  t  >  [D1,D2jE  E/  =>  [ft,  ftj  (E,E',E') 

£'  [Sx,S2]^R2  — ►*  [ft,ft]g,§,Ei) 


by  the  Weakening  Lemma  6.4  3)  on  £2, 
by  rule  sexTtn  on  ft  and  ft. 
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Observe  that  a  single-step  parallel  firing  is  mapped  to  a  multi-step  sequential  execution.  The  multi-step  parallel  case  builds 
on  the  result  we  just  proved  and  is  obtained  by  a  simple  induction  on  the  derivation  £. 

The  reverse  direction  of  this  theorem  is  proved  as  follows:  we  wrap  each  one-step  sequential  firing  with  one  application 
of  rule  pex_par  by  means  of  an  instance  of  rule  pex_id  with  empty  state  and  active  role  set.  The  multi-step  case  mimics  the 
corresponding  sequential  construction  with  parallel  iteration  rules.  □ 

This  result  allows  us  to  focus  our  efforts  on  the  rules  for  sequential  execution:  any  property  proved  valid  for  the  sequential 
case  can  immediately  be  ported  to  the  parallel  setting  by  using  the  appropriate  direction  of  the  above  theorem.  This  does  not 
mean,  however,  that  we  should  do  without  parallel  execution  and  eliminate  its  rules  from  our  formalization:  this  form  of 
execution  is  more  faithful  to  the  behavior  of  protocols  in  a  distributed  environment  and  therefore  constitutes  a  more  adequate 
model  of  their  execution.  The  fact  that  parallel  execution  can  be  serialized  does  not  imply  that  the  resulting  sequential 
behavior  is  better  and  should  be  adopted. 


6.4  Type  Preservation 


This  section  is  dedicated  to  exploring  the  relationship  between  the  simulation  semantics  outlined  in  Section 


6.2  and  the 


constraints  on  sensible  objects  provided  by  the  typing  rules  in  Sections  [2||4]  (and  summarized  in  Appendix |A. 2 1.  Our  main 
result  will  be  the  Type  Preservation  Theorem  |6.15|  which  certifies  that  execution  preserves  typability:  when  starting  with 
well-typed  objects,  firing  will  always  produce  well-typed  entities.  This  property  is  an  important  sanity  check  concerning 
the  interaction  of  the  typing  and  execution  rules  in  our  system.  On  the  other  hand,  it  has  useful  implications  for  actual 
implementations  of  MSR.  It  should  be  noted  that  aspects  of  the  proof  of  this  result  concern  specific  constructs  in  our  term 
language.  Therefore,  whenever  extending  this  language  for  a  particular  application,  we  shall  adapt  the  proof  to  the  new  syntax 
and  inference  rules. 


The  proof  of  the  type  preservation  theorem  makes  use  of  a  number  of  lemmas.  Some  address  minor  technical  issue,  while 
others  are  of  a  more  general  importance.  We  start  with  the  Weakening  Lemma,  a  general  result  that  asserts  that  whenever  a 
judgment  is  derivable,  it  remains  so  in  the  presence  of  additional  assumptions  in  its  signature  and/or  context. 


Lemma  6.6  ( Weakening ) 

Let  X,  X'  be  a  signature,  T  and  T'  typing  context  fragments,  and  T"  F  X  :  Y  a  typing  judgment  among 
T"  F  t  :  T  T"  F  t:  T  T"  F  r  T"  hr  T"  F  P  T"  F  Ihs  T"  F  rhs  T"  hr  T"  F  p  T"  F  V  T"  F  R 
(Y  is  defined  only  for  judgments  with  two  objects  on  the  right  of  the  turnstile  symbol .) 

If  (E,T)  F  X  :Y,  then  (X,X',r,r')  \-  X  :Y. 

Proof:  This  proof  proceeds  by  induction  on  the  structure  of  a  derivation  for  the  given  judgment.  We  omit  it  because  of  its 
extreme  simplicity.  □ 


Our  next  result  is  quite  technical:  it  affirms  that  whenever  a  state  is  well-typed,  so  is  any  substate;  viceversa  if  a  number 
of  substates  are  typable  with  respect  to  a  common  signature,  their  union  is  typable. 

Lemma  6.7  ( State  Merge/Join) 

Let  Y,  be  a  signature,  and  S\  and  S2  two  states.  Then,  Yi  F  (Si,Sf)  if  and  only  if  £  h  Si  and  X  F  5'2- 

Proof:  The  forward  direction  is  a  simple  induction  on  the  the  structure  of  a  derivation  for  the  given  judgment.  In  the  reverse 
direction,  the  induction  proceeds  on  the  structure  of  a  derivation  for  the  judgment  X  F  52-  □ 


The  following  Variable  Scoping  Lemma  that  asserts  that  a  variable  cannot  occur  in  a  context  before  it  has  been  declared. 
Lemma  6.8  ( Variable  Scoping ) 

Let  r  and  I  '  be  contexts,  x  a  variable,  t  a  type  and  t  a  term.  If  F  (T,  x  :  r,  T7),  then  [t/x\T  =  T  and  \t/x\r  =  r. 
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Proof:  Applying  the  context  typing  rules  will  eventually  reveal  the  judgment  F  (r,  x  :  r),  to  which  only  rule  ctp_x  is 
applicable.  Its  premises  are  F  T  and  T  F  r.  The  conclusion  of  the  lemma  can  be  violated  only  if  T  or  r  contain  free 
occurrences  of  x.  If  this  were  the  case,  rule  mtp  a  would  eventually  be  applied,  which  entails  that  T  contains  a  declaration 
for  x.  This  would  however  violate  our  requirement  that  typing  contexts  contain  at  most  one  declaration  for  each  variable. 

A  formal  proof  proceeds  by  induction  on  the  structure  of  a  derivation  for  the  given  judgment.  □ 

The  next  lemma  verifies  that  subtyping  is  invariant  with  respect  to  term  substitution.  This  property  needs  to  be  checked 
over  when  modifying  the  subtyping  relation. 

Lemma  6.9  ( Subtyping ) 

Let  t  and  t'  be  two  types.  If  r  ::  t' ,  then  [t/x]r  ::  \t/x\r'  for  any  variable  x  and  term  r. 

Proof:  This  result  is  obtained  by  inspection  of  the  subtyping  rules  for  our  language.  □ 

The  following  lemma  spells  out  the  effect  of  compound  substitutions  under  some  assumptions  about  where  variables 
occur. 

Lemma  6.10  ( Compound  Substitutions) 

Let  X,  t  and  t  be  a  signature,  a  term  and  a  type  such  that  X  F  t  :  t  is  derivable.  Let  moreover  x  and  y  be  variables,  t' 
be  another  term  ( possibly  containing  x)  and,  O  be  either  a  term  t" ,  a  type  t'  or  a  tuple  type  t  ( possibly  containing  x  and  y 
free).  Then  the  following  equality  holds: 


[t/x\([t'/y}0  =  [[t/x]t'/y]([t/x\0) 


Proof:  This  property  is  proved  by  induction  on  the  structure  of  O  and  the  definition  of  substitution  for  terms,  types  and  tuple 
types.  We  will  examine  four  representative  situations:  the  three  cases  where  O  is  a  variable  (x,  y,  or  another  variable  z)  and 
the  case  where  O  is  a  non-empty  tuple  type. 


O  =  x 

[t/x\{[f /y\x) 


o  =  y 

[t/x\([t'/y\y) 


O  =  z 

Wx]([t'/y)z) 


O  =  T/(Z)  X  T 

[t/xW/y}(r'^  x  f)) 


t 

[[t/x]t'/y]t 
[[t/x\t' /y]{[t/x\x) 


by  definition  of  substitution, 
since  t  is  ground  by  assumption, 
by  definition  of  substitution. 


\t/x]t' 

[[t/x]t'/y\y 
\[t/x]t'  /y\{[t/x]y) 


by  definition  of  substitution, 
by  definition  of  substitution, 
by  definition  of  substitution. 


z 

[[t/x]t'/y]([t/x]z) 


by  definition  of  substitution, 
by  definition  of  substitution. 


([t/x\([tr /y]^))^  x  (\t  /  x\(\t' /  y]f))  by  definition  of  substitution, 

([[t/x]f /y\([t/x\T,))(-z'>  x  ([[t / x]f  / y\({t / x\f))  by  induction  hypothesis, 

[[t/x]t' /y]([t/x](T'^  x  t))  by  definition  of  substitution. 
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The  other  possibilities  are  treated  similarly  to  the  last  case  considered. 


We  now  move  to  a  fairly  general  result  about  the  effect  of  substitutions  on  valid  typing  judgments.  Whenever  a  judgment 
mentions  a  variable  x  of  type  r,  replacing  every  occurrence  of  x  with  a  term  of  the  same  type  maintains  typability,  assuming 
that  some  simple  preconditions  are  met.  The  exact  text  of  this  lemma  is  as  follows: 

Lemma  6.11  ( Term  Substitution) 

Let  E  and  S'  be  signatures,  t  a  term,  r  a  type,  x  a  variable,  T  a  context  fragment,  and  T1  \~  X  :  Y  a  typing  judgment 
among 

r  f  t'  :t'  r'hpf  r  h  r'  r'hf  r  f  p  r  f  ihs  r  f  rhs  r  p  r  rip 

(Y  is  defined  only  for  judgments  with  two  objects  on  the  right  of  the  turnstile  symbol .) 

If  E,  E7  F  t  :  t,  F  (E,a;  :  r,  T)  and  (E,a;  :  r,  T)  F  X  :  Y,  then  (E,E7,  [f/:r]r)  F  [t/x\X  :  \t/x\Y. 

Proof:  The  proof  of  this  lemma  proceeds  by  induction  on  a  derivation  T  of  the  judgment  (E,  x  :  r,  T)  F  X  :  Y.  Let  Tt 
and  7r  be  derivations  for  the  term  and  context  typing  judgments  given  in  the  premise  of  this  result.  We  will  spare  the  reader 
a  detailed  account  of  this  long  proof  and  instead  concentrate  on  a  few  significant  cases  for  the  last  rule  applied  in  T.  We 
start  with  situations  where  rule  mtp  a  has  been  applied.  We  must  distinguish  three  subcases  depending  on  whether  the  object 
being  validated  is  a  constant  a  declared  in  E,  the  variable  x  itself,  or  another  variable  y  defined  in  T.  We  will  then  examine 
rules  mtp_ss,  mtp_pke,  mpt_ext,  and  rtp_nnc. 


mtp_a  (1) 


r  = 


(Ei,  a  :  t',  E2,  x  :  r,  T)  F  a  :  t' 


■  mtp_a 


with  E  =  (Ei,  a  :  r',  E2),  X  =  a  and  Y  =  t' . 

a  =  \t/x\a 
t'  =  [t/x\r' 

V  ::  (E1;  a  :  t',  E2,  E',  \t/x\T)  F  a  :  r' 


by  definition  of  substitution, 

by  the  Variable  Scoping  Lemma  6.8  on  7r, 

by  rule  mtp_a. 


mtp_a  (2) 


T  = 


(S,  x  :  r,  T)  F  x  :  t 
with  X  =  x  and  Y  =  r. 

t  =  [t/x\x 
t  =  [t/x\r 

V  ::  (E,  S',  [t/x]T)  F  t  :  r 


mtp_a 


by  definition  of  substitution, 

by  the  Variable  Scoping  Lemma  6.8  on  7r 


by  the  Weakening  Lemma  6.6  on  Tt- 


mtp_a  (3) 


T  = 


(E,z  :  T,Fi,y  :  t',T2)  F  y  :  r' 


■  mtp_a 


with  L  =  (Ti,  y  :  r',r2)  for  y  ^  x,  X  =  a  and  Y  =  t' . 

T'  ::  (E,  E',  [f/a:]r)  F  y:[t/x]r'  by  rule  mtp_a  and  the  definition  of  substitution. 


mtp_ss 


with 


Ti  r2 

(S,*:r,r)  F  t'  :t"  t"  ::  t' 

T= - 

(E,  x  :  r,  T)  F  t'  :  t' 

X  =  f  and  Y  =  t'. 


mtp_ss 
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T{  ::  (£,£',  [*/®]r)  F  [t/x]t' :  [t/x]r" 

V  "  [t/xV  [t/xV 

T'  ::  (E,  £',  \t/x\T)  F  \t/x]t'  :  \t/x\r' 


by  induction  hypothesis  on  71, 
by  the  Subtyping  Lemma  6.9  on  72, 
by  rule  mtp_ss  on  T{  and  77- 


71 


r2 


mtp  pke 


(E,  x  :  r,  T)  F  t'  :  msg  (£,  a;  :  r,  T)  F  k  :  pubK  A 

7~  =  -  mtp_pke 


(E,a;  :  r,  T)  F 


\k  '■  msg 


with  X  =  jjT']}*.  and  Y  =  msg. 


V 

V 

V 


(E,  £',  [t/x]T)  F  \t/x\t'  :  msg 

(E,  E',  [t/x]r)  h  [t/x\k  :  [f/x](pubK  A) 

(E,  E',  [t/a;]r)  h  [t/x)lt'Jk  ■  msg 


by  induction  hypothesis  on  71, 
by  induction  hypothesis  on  71, 

by  rule  mtp_pke  on  T{  and  7^,  and  definition  of  substitution. 


71  71 

(E,a;  :  r,  T)  h  f'  :  t'  (E,a;  :  r,  T)  h  T: 


mtp  ext 


T  = 


(E,a:  :  r, T)  h  (t1  ,t)  :  t'^  x  t 


mtp_ext 


with 

X  =  (t 

, t )  and 

Y  =  t' 

[ y )  -» 

X  T. 

V  : 

(£,£', 

[t/x}T)  F 

[t/x]tr 

:  [t/xy 

V  : 

(£,£', 

[t/x]T)  F 

[t/x]t 

WxW 

V 

(£,£', 

[t/x]T)  F 

[t/x]t  : 

\[t/x]t'/ 

V  : 

(s,  s', 

[t/x]T)  F 

[t/x\(t 

[t/x\(r 

x  r) 

by  induction  hypothesis  on  71, 
by  induction  hypothesis  on  71, 
by  Lemma  6.10  on  71, 

by  rule  mtp_ext  on  T[  and  and  definition  of  substitution. 


rtp_nnc 


71  71 

(E,x:r,  r)  h  t'  (E,  x  :  r,  T,  y  :  t')  F  rhs 

T  =  - rtp_nnc 

(E,  x  :  r,  T)  F  3 y  :  t' .  rhs 


with  X  =  By  :  t' .  rhs. 


77  ::  (S,  S',  [f/x]T)  F  \t/x\r' 

77  ::  (E,  S',  [t/a;]r,  y  :  [t/ x]t')  F  [t/x]rhs 
T1  ::  (E,  E',  [t/ar]r)  F  [t / x\(3y  :  t' .  rhs) 


by  induction  hypothesis  on  71, 
by  by  induction  hypothesis  on  71, 

by  rule  rt.p  nnc  on  77  and  71',  and  definition  of  substitution. 


The  other  possible  last  rules  for  the  derivation  T  are  treated  similarly  to  the  cases  we  just  discussed.  Most  such  rules  follow 
the  pattern  seen  when  processing  rule  mtp  pke.  □ 

The  previous  result  has  a  counterpart  regarding  role  state  predicate  parameters.  We  have  the  following  lemma,  where  the 
array  of  judgments  to  consider  is  reduced  by  the  limited  syntactic  situations  in  which  such  a  parameter  can  occur. 

Lemma  6.12  (Role  State  Predicate  Constant  Substitution) 

Let  E  and  S'  be  signatures,  L;  and  L  a  role  state  predicate  constant  and  variable  respectively,  t  a  tuple  type,  T  a  context 
fragment,  and  T'  \~  X  a  typing  judgment  among 
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T'h  P 
If  P  X,  L;  :  r,  X', 


F  P  Ihs  F  F  r/is  T'hr  F  P  p 

F  (X,  L  :  r,  T)  W  (X,L:f,T)  P  X,  t/ien  (X,  L;  :  r,  X',  T)  P  [L i/L\X. 


Proof:  The  proof  of  this  result  is  similar  to,  but  simpler  than,  the  proof  of  the  Term  Substitution  Lemma  [6. 11 
of  brevity,  we  refrain  from  expanding  it. 


For  the  sake 

□ 


Our  last  auxiliary  lemma  verifies  that  valid  executions  of  the  right-hand  side  instantiation  judgment  respect  type  preser¬ 
vation.  We  have  the  following  result: 

Lemma  6.13  (Type  Preservation  for  Right-Hand  Side  Instantiation) 

Let  X  and  X'  be  signatures,  rhs  a  rule  right-hand  sides,  and  Ihs  a  predicate  sequence  such  that 

{rhs)s  »  (lhs)v 

If  the  following  typing  judgments  hold 

P  X  X  F  rhs 

then  the  following  judgments  are  derivable 

1)  P  X'  2)  X'  P  Ihs. 


Proof:  The  proof  proceeds  by  induction  on  the  structure  of  a  derivation  £  for  the  instantiation  judgment  ( rhs ) y,  2>  (lhs)v 
and  inversion  on  a  derivation  Trhs  for  the  typing  judgment  X  F  rhs.  Let  7s  be  the  given  signature  derivation.  We  verify 
that  the  property  holds  for  the  two  rules  that  can  possibly  appear  in  this  derivation. 


sex_seq 


This  situation  is  immediate  since  X'  =  X  and  Ihs  =  rhs. 
£' 


([a /x]rhs)(Eia;T)  >  (Z/is)s' 

sexjllic  £  =  - -  sex_nnc 

(3x  :  r.  r/is')s  >  (i/is)s' 
with  rhs  =  3x  :  t.  rhs' . 


Tr  ::  X  F  r 
Trhs’  ::  X,  x  :  r  F  rhs 
7s,a  ::  F  X,a  :  r 
7s, x  ::  F  E,x  :  r 
Ta  ::  X,  a  :  r  F  a  :  r 
T’rhs,  ::  X,  a  :  r  F  [a /x]rhs' 
Tv  v.  F  X' 

Tihs  "  X'  F  Ihs 


and 


by  inversion  on  Trhs  using  rule  rtp_nnc, 
by  rule  itp_a  on  77  and  7s, 
by  rule  ctp_sig  on  7s  and  then  ctp  x  on  77, 
by  rule  int  p  a, 

on  %,  Tt.,x  and  Trhs', 


6.11 


by  the  Substitution  Lemma 
and 

by  induction  hypothesis  on  7s. a  and  Tjhs. 


Lemma  6.14  (Type  Prescription  for  Rule  Application) 

Let  r  be  a  rule  ,  X  and  X'  signatures,  and  S  and  S'  states  such  that 

r>  [51]  s  ^  [*S'/]  s'  • 

If  the  following  typing  judgments  hold 

FX  X  F  r  X  P  S' 

then  the  following  judgments  are  derivable 

1)  F  X'  2)  X'  F  r  3)  X'  F  S'. 
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Proof:  The  proof  proceeds  by  induction  on  the  a  derivation  £  of  the  execution  judgment  r  c>  [5]  s  [5']  s,.  Let  7s,  77,  and 
7s  be  the  given  typing  derivations,  where  the  subscripts  match  their  respective  right-hand  sides.  We  consider  the  following 
possible  last  rules  for  £: 


sex_all 


with 


77  £' 

XI-  t  :  t  [t/x\r'  >  [5]  s  [5']  s, 

£  =  -  sex_all 

(Va;  :  r.  r')  c>  [S]  E  >  [S']  E, 
r  =  (Va;  :  r.  r'). 


77  : :  XI  t 
77'  "  X,  x  :  r  h  r' 
Ty.,x  ::  F  X,  a;  :  r 
r;  ::  X  h  [f/x]r' 

:=  I"  S' 

73  ::  X'  h  S' 
r;  ::  X'  h  Va;  :  r.  r' 


and 


by  inversion  on  rule  utp  all  for  77, 

by  rule  ctp  x  on  7>;  and  77, 

by  the  Substitution  Lemma  6.11  on  77,  7sjX  and  77', 

and 

by  induction  hypothesis  on  £',  7s,  77',  and  7s, 


by  Lemma  6.2  on  £'  and  the  Weakening  Lemma  6.6  on  77- 


£' 

(rhs) s  »  (Ihs')s' 

sex.core  I  £  =  -  sex_core 

-  ( Ihs  -¥  rhs)  t>  [S*,  Ihs]  E  »  [5*,  Tis']  E, 

with  r  =  (Z/is  — >•  rfts),  51  =  (S*,  Ihs),  and  S'  =  (S* ,  Ihs'). 


Ts *  ::  X  h  S* 
Tihs  "XI-  Ihs 
Trhs  ■■  X  F  rhs 

U  ::  h  X' 

Tihs'  ::  X'  h 

Ti  ::  X'  h 

r;  ::  X'  h  r 


and 


by  the  State  Splitting  Lemma  6.7  on  7s, 
by  inversion  on  rule  utp_core  for  77, 
and 

by  the  Instantiation  Lemma  6.13  on  £',  7s  and  77/is, 
by  Lemma  I 


6.6 


on  7s*  and  then  Lemma  6.7  on  77 


•  Ihs' 


by  Lemma  6.2  on  £'  and  the  Weakening  Lemma  6.6  on  77- 


□ 


We  are  now  in  a  position  to  state  and  prove  the  main  result  of  this  section.  The  Type  Preservation  Theorem  asserts  that  if 
we  start  from  a  snapshot  in  whose  signature  the  protocol  theory,  the  initial  state  and  the  initial  active  role  set  are  typable,  then 
the  application  of  an  execution  sequence  will  yield  a  snapshot  where  all  the  corresponding  objects  are  typable. 

Theorem  6.15  {Type  Preservation) 

Let  V  be  a  protocol  theory,  X  and  X'  signatures,  R  and  R'  active  role  sets,  and  S  and  S'  states  such  that 

V»[S]«  — [<?']*;. 

If  the  following  typing  judgments  hold 

LX  XhP  Xhi?  X  h  s 

then  the  following  judgments  are  derivable 

1)  h  X'  2)  X'  h  V  3)  X'  h  R'  4)  X'  h  S'. 
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Proof:  The  proof  proceeds  by  induction  on  the  a  derivation  £  of  the  execution  judgment  V  >  [S]  — >(*)  [,SV]  .  Let 

7s,  Tp,  Tr,  and  72  be  the  given  typing  derivations,  where  the  subscripts  match  their  respective  right-hand  sides.  In  the 
following,  we  will  limit  our  analysis  to  the  most  significant  cases,  and  sketch  the  proof  of  the  simplest  situations.  We  consider 
the  following  possible  last  rules  for  £ : 


sex_arole 


£  = 


m  ->  [s]E 

with  V  =  (V*,pA)  and  R'  =  {R,pA). 


R,p 


sex_arole 


Since  only  the  active  role  set  differs  in  the  snapshots  considered  in  this  rule,  we  only  need  to  prove  the  validity  of  point 
(3)  of  the  theorem.  This  very  simple  proof  goes  as  follows: 

X  =  (Xi,  A  :  principal,  X2)  and 

Tp  ::  X  h  p  by  inversion  on  rule  htp_arole  for  Tv, 

Tft  ::  X  h  f?,  pA  by  rule  atp_ext  on  Tr  and  Tp, 


sex_rsp 


£  = 


V>  [S]£*’( 3i:f-p)A 


.  sex_rsp 


rot  /£]p)a 


with  R  =  ( R *,  (3 L  :  f.  p)A),  Rf  =  (f?*,  ([L i/L]p)A)  and  S'  =  (X,  L*  :  f). 

The  changes  to  the  resulting  signature  force  us  to  prove  all  part  of  the  theorem  in  this  case. 

and 
and 
and 

by  inversion  on  rules  at.p  ext  and  otp  rsp  for  Tr , 
by  rule  ctp_sig  on  72  and  then  ctp_rsp  on  Tf, 
by  rule  itp_rsp  on  7s  and  Tf, 


Tr . 

:  X 

h  iT 

X  = 

£ 

1,  A  : 

pri 

ncipal,  X2) 

Tf  : 

X 

h  t 

TP  : 

S, 

L  :  t 

h 

P 

72, l 

:F 

X,  L  : 

T 

72  : 

h 

X,  L; 

T 

TP'  : 

s, 

U  ■  T 

h 

[L  i/L\p 

Tk  : 

s, 

Li  :  T 

h 

R*,([U/L]p) 

T'  • 
's  • 

S, 

Li  :  t 

h 

S 

T'  • 
'V  • 

S, 

Li  :  r 

h 

V 

sex_rule 


£' 


rt>  [5]  E  [S']  E, 


£  = 


[S]f’(r’p)A  — ■>  [S']"’ 


n^;,(P)A 

with  R  =  (R*,  ( r ,  p)A),  R'  =  {R*,  (p)A). 

This  rule  relies  on  our  last  lemma. 

Tr *  ::  X  h  R* 


-  sex_rule 


and 


X 

=  (Xi,  A  :  principal,  X2) 

and 

TP 

::  X  h  p 

and 

Tr 

::  X  h  r 

by  inversion  on  rules  atp  ext  and  ot  p  ride  for  Tr, 

T' 

'e 

::  h  X' 

and 

T' 

'S 

::  X'  h  S' 

by  the  Instantiation  Lemma  6.14  on  £',  72,  T  and  72- 
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::  X  b  ir,(p)A 
Tfi  ::  S'  b  V 


by  Lemma  6.6  on  Tr*  and  Tp,  and  then  rule  atp_ext. 


by  Lemma  6.2  on  £'  and  the  Weakening  Lemma  6.6  on  Tp. 


Rule  sex_grole  is  treated  similarly  to  rule  sex_all.  Rule  sex_skp  is  processed  along  the  lines  of  rule  sex_rsp,  although  in  a 
much  simpler  way.  Rule  sex_dot  is  immediate. 

A  simple  inductive  argument  proves  the  cases  of  rules  sex_itO  and  sex_itn,  which  implement  the  transitive  closure  of 
atomic  transitions.  □ 

By  virtue  of  the  Admissibility  Theorem |6. 5 [  a  similar  result  clearly  holds  for  parallel  firings.  For  space  reasons,  we  refrain 
from  showing  its  statement. 

In  many  languages,  the  validity  of  a  type  preservation  theorem  has  one  important  implication:  types  are  not  needed  at 
run  time.  This  allows  for  a  convenient  and  efficient  separation  of  phases:  in  a  first,  static,  phase,  the  specification  at  hand  is 
checked  for  type  consistency.  In  a  second,  dynamic,  phase,  execution  is  emulated  without  any  reference  to  types.  Therefore, 
the  data  structures  used  at  run-time  do  not  need  to  record  and  maintain  typing  information,  with  significant  speed  advantages. 

These  benefits  of  type  preservation  do  not  apply  in  full  in  the  case  of  MSR.  Indeed,  rules  sex_grole  and  sex_all  directly 
invoke  the  typing  judgment  to  instantiate  variables  with  terms  of  the  proper  type.  We  will  discuss  operational  improvements 
to  these  rules  in  Section [7]  and  show  that  in  many  situations,  type  correctness  is  guaranteed.  We  will  however  also  see  that 
there  are  circumstances  where  omitting  a  run-time  type-check  would  result  in  violations  of  the  Type  Preservation  Theorem. 


6.5  Data  Access  Specification  Preservation 


This  section  explores  the  relationship  between  execution  and  data  access  specification.  Our  main  achievement  will  be  a 
preservation  result  for  data  access  specification  (Theorem  |6. 1 9[>:  it  states  that,  under  reasonable  typing  assumptions,  no 
execution  sequence  can  take  a  snapshot  that  satisfies  the  data  access  specification  policy  to  a  situation  that  violates  it.  As 
in  the  case  of  typing,  this  property  provides  an  important  sanity  check  about  the  correctness  of  our  data  access  specification 
rules.  It  also  implies  that  it  is  sufficient  to  verify  that  the  specification  of  a  protocol  satisfies  the  data  access  specification 
policy  once  before  any  execution  is  undertaken. 


In  order  to  establish  this  property,  we  will  rely  on  the  same  techniques  already  used  for  the  Type  Preservation  Theo- 


6.15  In  particular,  we  need  to  prove  a  number  of  auxiliary  properties,  that  are  the  data  access  specification  equivalents 


of  some  of  the  lemmas  given  in  Section  6.4  We  start  with  the  following  Weakening  Lemma: 


Lemma  6.16  ( Weakening ) 

Let  X  and  X'  be  signatures,  T  a  typing  context  fragment,  A  a  knowledge  context,  A  a  principal  name  or  variable,  and 
T7;  A  lbA  X  >  Y  Z  an  data  access  specification  judgment  among 

r;  A  IP,  k  »  A7  T7;  A  IPA  k  >  A7  T7;  A  lb*  f >  A7  T7;  A  lbA  Ihs  >  f»  A7 

r7  S->A  e  T;AS->a  t'  TjAS-tt  t  T'jAt-^  Ihs  T7;A  lbA  rhs 

T7  I  Pa  r  T7  lbA  p  X"  lb  V  X"  lb  R 

(Y  and  Z  are  defined  only  for  judgments  with  more  than  two  (resp.  three)  objects  to  the  right  of  the  turnstile  symbol;  A  and 
A  do  not  appear  in  the  last  two  judgments..) 

If  (X,  T);  A  lbA  A'  >  Y  >  X,  then  (X,  X7,  T);  A  lbA  A  >  Y  >  X. 


Proof:  This  routine  proof  proceeds  by  induction  on  the  structure  of  a  derivation  of  the  given  data  access  specification  judg¬ 
ment.  We  will  spare  the  reader  its  long  and  tedious  development.  □ 


The  next  auxiliary  result  we  need  is  the  data  access  specification  equivalent  of  the  Term  Substitution  Lemma [6.1  l|proved 
in  the  previous  section.  The  statement  of  this  property  is  rather  involved  in  an  attempt  to  provide  a  succinct  characterization 
for  the  numerous  judgments  participating  in  data  access  specification.  It  should  be  noticed  that  its  validity  makes  use  of 
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typing  assumptions,  used  to  support  the  informal  requirement  made  in  section  [5]  that  all  objects  appearing  in  our  data  access 
specification  rules  should  be  well-typed. 

Lemma  6.17  (Term  Substitution) 

Let  X  and  S'  be  signatures,  t  a  term,  r  a  type,  x  a  variable,  and  T  a  typing  context  fragment  such  that  the  judgments 
X,X'  h  t  :  r  and  K1  (X,,t  :  r,  T)  hold.  Furthermore, 

•  let  A  be  a  knowledge  context,  A  a  principal  constant  or  variable,  and  T';  A  ll-A  X  >  Y  Z  an  data  access 
specification  judgment  among 

r;  a  ipa  k  >  a'  r;  a  rA  k  >  a7  r;  a  ii-a  t »  a'  r;  a  ii-a  //is  >  a7 

r  S->A  e  r;AS->A  £'  TjATa  t  TjAl-*,  Z/is  r7;A  ll-A  rhs 

r  ih*  r  r  lbA  p 

(T  a«c/  X  are  defined  only  for  judgments  with  more  than  tw’o  (resp.  three)  objects  to  the  right  of  the  turnstile  symbol.) 
If  (X,  x  :  t,  T);  A  lbA  X  >  Y  >  Z,  then  (X,  X',  [t/x]T);  [f/x]  A  lh[t/x]A  [t/x]X  >  [t/x]Y  >  [f/x]Z 

•  Zef  A  ant/  A'  be  knowledge  contexts  and  t  a  tuple  consisting  of  either  ground  terms  or  variables. 

If  A  >  t  >  A',  then  [i/x]A  >  [t/x]t  >  [£/x]A' 

Proof:  This  proof  proceeds  by  induction  on  the  structure  of  a  derivation  A  for  the  given  data  access  specification  judgments. 
Let  7t  and  7r  be  derivations  for  the  assumed  term  and  context  typing  judgments,  respectively.  The  number  of  cases  to 
examine  is  considerable  due  to  the  many  rules  that  implement  data  access  specification,  and  to  the  fact  that  some  of  these 
rules  require  a  detailed  analysis  of  several  subcases.  For  the  sake  of  brevity,  we  will  describe  the  treatment  of  three  significant 
rules:  kac_sul,  lac_rsp,  and  rac_nnc.  The  first  of  these  has  three  subcases. 

(X,  x  :  r,  T1;  k  :  shK  A  B,  T2);  A  IFA  Zc^>(A,fc) 
with  r  =  (Ti,fc  :  shK  AB,r2)  X  =  k,  and  Y  =  (A,  k) 

Ax  ::  (X,  X',  [£/x]Ti,  k  :  shK  {[t/x]A)  (\t/x\B),  [£/x]T2);  [f/x]A  by  rule  kac_sul, 

[t/x]k  »  ([£/x]A,  \t/x]k) 

Ax  ::  (X,  X',  [£/x](Ti,  k  :  shK  A  B,  T2));  [£/x]A  IP[t/a,]A  [t/x]k  [i/x](A,  k)  by  definition  of  substitution. 


kac_sul  (1) 


kac_sul  (2)  A  = 


(X,  x  :  shK  A  B ,  T);  A  IPA  x  (A,  x) 
with  t  =  s\\KAB  X  =  x,  and  Y  =  (A,x) 


kac_sul 


X,X'=(Xi,f  :  shK  AB,Y2) 

A  =  [t/x\A 

X2  =  [£/x]X2 

A'  ::  (Xi,  t  :  shK  A  B,  X2,  [t/x]T)\  [t/x\A  IPA  t  (\t/x\ A,  t) 


by  inversion  on  rule  mpt_a  for  7t, 
and 


by  the  Variable  Scoping  Lemma  6.8  on  7r, 
by  rule  kac_sul  and  definition  of  substitution. 


kac_sul  (3)  A  = 


kac_sul 


(X1;  k  :  shK  A  B,Y,2:x  :  t,  T);  A  IPA  k  (A,  k) 
with  X  =  (Xi,  k  :  shK  A  B,  X2)  X  =  k,  and  Y  =  (A,k) 

This  last  subcase  results  from  a  combination  of  the  reasoning  performed  in  the  last  two  situations. 
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lac  rsp 


with 


A\  A2 

A  >  (A,e)  >  A'  (E,®  :  r, T);  A'  lbA  Ihs  >  t'  »  A" 

—  -  lac_rsp 

T);A  lbA  (L(A,  e ),  Ihs)  >  t'  A>  A" 

X  =  (L(A,e),  Ihs),  Y  =  t,  and  Z  =  A" 


A  i 
A'2 
A' 


[i/a;]A  >  \t/x\(A,e)  >  [t/x\ A' 

(E,  X/,  \t/x\T)]  [t/x\ A’  \\-[t/x]A  [t/x\lhs  >  [t/x\t'  >  [t/x\ A" 
('E,Y,',[t/x}T)-1[t/x\A  I b[t/aj]A  [t/x\(L(A,  e),  Ihs)  >  [t/x)t'  >  [f/a;]A" 


by  induction  hypothesis  on  Ai, 
by  induction  hypothesis  on  A-j, 

by  rule  rac  nnc  on  A\  and  A)  and 
definition  of  substitution. 


Arhs 


(S,  x  :  t,  T,  y:  r');  (A,  y)  \\-A  rhs 

rac_nnc  I  A  =  -  rac_nnc 

(S,x:r,r);A  lhA  By -.t1.  rhs 
with  X  =  (By  :  t'  .  rhs) 


A'rhs  ::  (S,  S',  [t/x](T,  y  :  r'));  [t/x}( A,  y)  H-[t/„]j4  [t/x\rhs  by  induction  hypothesis  on  Arhs, 

A!  ::  (S,  S',  [f/x]r);  [f/a;]A  II- [t/x\(By  :  r'.  rhs)  by  rule  rac  nnc  on  A'rhs  and  definition  of  substitution. 


The  remaining  rules  are  treated  similarly  and  will  not  be  discussed  further. 


□ 


We  need  a  similar  result  in  order  to  make  substitutions  to  role  state  predicate  parameters.  This  property  is  formally 
captured  in  the  following  lemma: 

Lemma  6.18  ( Role  State  Predicate  Constant  Substitution ) 

Let  X  and  S'  be  signatures,  L/  and  L  a  role  state  predicate  constant  and  variable  respectively,  r  a  tuple  type,  T  a  typing 
context  fragment,  A  a  knowledge  context,  and  l7;  A  lhA  X  >  Y  A>  Z  an  data  access  specification  judgment  among 

T';  A  IP*  Ihs  >  f>  A'  FjAS-u  Ihs  T7;  A  lhA  rhs  T'  \\-A  r  Fib Ap 

(Y  and  Z  are  defined  only  in  the  first  of  these  judgments;  A  does  not  appear. ) 

If  b  E,L,  b  (X,  L  :  f,T)  and  (X,L:f,T);  A  lbA  X  >  Y  >  X,  then  (X,X',T);A  lbA  [L i/L\X> 

Y  Z. 


Proof:  This  result  is  proved  similarly  to  the  Term  Substitution  Lemma  6.17  There  are  fewer  cases  to  consider  since  role 
state  predicate  parameters  can  occur  only  in  a  limited  number  of  syntactic  constructions.  □ 


At  this  point,  we  have  all  the  necessary  tools  to  produce  a  direct  proof  of  the  main  result  of  this  section.  The  Data  Access 
Specification  Preservation  Theorem  below  states  that,  given  a  protocol  theory  and  an  active  role  set  that  satisfies  data  access 
specification  (and  are  well-typed)  in  the  current  signature,  every  execution  sequence  will  produce  a  snapshot  whose  active 
role  state  is  compliant  with  the  data  access  specification  policy. 

Theorem  6.19  ( Data  Access  Specification  Preservation) 

Let  V  be  a  protocol  theory,  X  and  X'  signatures,  R  and  R'  active  role  sets,  and  S  and  S'  states  such  that 

To  [5]g  — [S']$  bX  XbP  XbJi 

If  the  following  data  access  specification  judgments  hold 

X  lb  V  X  lb  R 
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then  the  following  judgments  are  derivable 

1)  X'  lb  V 


2)  S'  lb  R' 


Proof:  To  carry  out  this  proof,  it  is  convenient  to  use  a  presentation  of  the  execution  rules  that  bypasses  the  rule  application 


judgment  r  t>  [.S']  E  [,S"]  s,.  To  do  so,  we  simply  replace  rules  sex_all  and  sex_core  from  Section  6.2  with  the  following 
variants: 


X  b  t  :  r 


all' 


(r/is)s  » 


r>  [5] 


R,((\/x:t.  r,)p ) 


[5] 


R,U[t/x]r),p)k 


Pt>  {S,ihs}*’iilhs^rhs)’p)f'  — >  [s, ihs] £;(p)A 


■  sex.core 


Proving  that  these  two  rules  are  derivable  in  our  original  system  and  that  rules  sex_all  and  sex_core  are  admissible  in  their 
presence  is  left  as  an  easy  exercise  to  the  reader. 


With  this  in  place,  the  proof  of  the  desired  result  is  similar  to  the  proof  of  the  Type  Preservation  Theorem  6.15  We 
will  limit  its  illustration  to  the  cases  where  the  last  rule  applied  in  the  given  execution  derivation,  say  £,  is  either  sex  all  or 
sex.core.  We  will  use  the  names  7>j,  7~p,  Tr,  Ap,  and  Ar,  for  the  assumed  derivations  of  the  other  judgments,  in  the  order 
they  are  given. 

Tt 

X  b  t  :  t 


sex_all 


£  = 


>c_all 


P>  [S]“ 


R*  ,((Vtr:r.  r,)p ) 


E 


R",(([t/x\r),pf 


with  R  =  (R* ,  ((\/x  :  r.r),  p)A)  and  R’  =  (R*,  (([t/x\r),  p)A). 
Ar*  ::  X  lb  R*  and 


Ap 

Ar 

Tr 

Ts,a 

A'r 

A' 


X  lbA  p 

T,,x  :  t  lbA  r 

X  b  r 

F  X,  x  :  r 

X  lbA  [t/x\r 

X  lbA  R*,(([t/x\r),p)A 


and 

by  inversion  on  rules  aac  ext,  oac  ride,  and  uac  all  for  Ar, 
by  inversion  on  rules  atp_ext,  otp_rule,  and  utp_all  for  Tr, 
by  rule  ctp_x  on  7e  and  Tt, 
by  the  Substitution  Lemma  6.17  on  Tt,  Te,x  and  Ar, 
by  rules  oac_rule  and  aac_ext  on  Ar*  and  A'r. 


£’ 

( rhs)s  >  ( lhs')i 


sex_core 


£  = 


■  sex_core 


Vt>  [S* ,lhs\** X{lhs^rhs)’p)A 


D/1  R*jpr 


i  e  *  i  ths  j  E/ 

with  S  =  (S*,  Ihs),  R  =  (R*,  ({Ihs  rhs),p)A),  S'  =  (S*,  Ihs')  and  R'  =  (R*,  (p)A). 


Ar* 

An 


A) 

Af 


R 


:  X  lb  R* 

£  Fa  P 
X'  lb  R*,(p)A 
:  X'  lb  V 


and 

by  inversion  on  rules  aac_ext,  oac_rule  and  uac_core  for  Ar, 
by  Lemma  6.16  on  Ar*  and  Ap  and  then  rule  aac  ext, 


by  the  Weakening  Lemma  6.16  on  Ap. 


The  treatment  of  the  other  possible  final  steps  for  £  is  adapted  from  the  proof  of  the  Type  Preservation  Theorem  6.15  In 
particular,  rules  sex_grole  and  sex_rsp  make  use  of  the  Substitution  Lemmas  6.17  and  |6.18|  respectively.  The  other  cases 
are  immediate.  □ 
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Thanks  to  the  Admissibility  Theorem  6.5  this  property  can  be  extended  to  the  parallel  firing  judgments.  For  space  reasons, 
we  omit  further  developments. 


This  theorem  and  the  fact  that  the  execution  rules  do  not  depend  on  any  data  access  specification  judgment  makes  data 
access  specification  verification  a  purely  static  check,  that  need  to  be  perform  only  once  before  any  execution  is  undertaken. 
Additional  aspects,  mostly  related  to  implementation  issues,  will  be  touched  in  Section  [7] 


6.6  Changes 

As  done  at  the  end  of  the  previous  major  subdivisions  of  this  report,  we  conclude  this  section  with  a  discussions  of  the  changes 
in  the  execution  semantics  of  MSR  with  respect  to  previous  versions  of  this  formalism,  as  presented  in  [27  ,  30]. 

1.  In  our  previous  work,  the  basic  execution  step  of  MSR  consisted  in  the  application  of  a  protocol  rule:  instantiation  of 
the  variables  appearing  in  its  left-hand  side  happened  by  pattern  matching  with  the  current  state,  fresh  constants  were 
substituted  for  the  existential  parameters  in  its  consequent  and  any  additional  variable  was  instantiated  before  installing 
the  resulting  right-hand  side  back  into  the  state.  Since  rules  were  not  threaded,  there  was  no  need  to  load  an  active 
role  set  before  executing  them,  nor  was  there  any  point  in  “skipping”  a  rule.  The  execution  model  discussed  in  this 
document  has  clearly  a  finer  grain.  This  is  due  to  two  reasons:  on  the  one  hand,  our  more  detailed  specification  calls 
for  a  precise  description  of  how  execution  actually  happens.  In  particular,  we  make  the  instantiation  of  each  variable 
individually  observable  (rule  sex  all)  and  separate  this  process  from  the  actual  application  of  a  rule  (rule  sex  ride). 
On  the  other  hand,  special  provisions  are  required  to  handle  some  novelties  of  our  syntax,  in  particular  the  possible 
threading  of  protocol  rules  in  a  role  (rule  sex_skp),  the  presence  of  a  distinguished  role  owner  (rules  sex_arole  and 
sex_grole),  and  the  notion  of  active  role  (rule  sex_dot). 

2.  In  12711301,  the  universal  variables  (then  implicitly  quantified)  were  instantiated  by  pattern  matching  at  the  time  a  rule 
was  applied.  Our  current  model  is  apparently  more  non-deterministic  in  that  it  relies  on  some  guesswork  to  instantiated 
these  objects  before  the  current  state  is  accessed.  As  already  said,  this  model  is  purposefully  abstract  and  not  intended 
as  the  basis  for  an  implementation.  We  will  discuss  a  more  concrete  proposal  in  Section[7]  We  should  however  observe 
that  ll27l  [30,|  did  not  discuss  how  variables  that  appear  only  in  the  consequent  of  a  rule  ought  to  be  instantiated,  while 
our  current  proposal  treats  them  transparently. 

3.  As  mentioned  in  Section[4]  our  earlier  work  on  MSR  demanded  that  the  graph  obtained  by  chasing  the  role  state  predi¬ 
cate  names  in  a  specification  be  acyclic.  This  eliminated  the  possibility  of  roles  executions  that  required  an  unbounded 
number  of  steps,  a  major  simplification  in  the  proofs  of  the  decidability  results  of  I27il46ll.  Our  present  syntax  admits 
roles  where  the  corresponding  graphs  contain  cycles.  It  should  however  be  noted  that  our  execution  model  prevents 
taking  advantage  of  them  to  implement  a  looping  behavior:  parametricity  makes  role  state  predicates  unique  to  each 
individual  invocation  of  a  role.  The  rules  in  an  active  role,  which  realize  this  property,  are  however  processed  sequen¬ 
tially  without  any  possibility  of  jumping  back.  Still,  iteration  is  possible  in  MSR  thanks  to  the  introduction  of  memory 
predicates.  This  will  be  demonstrated  in  Section[9] 

4.  In  the  previous  versions  of  MSR ,  the  notion  of  execution  was  limited  to  sequential  firing  of  rules.  Parallel  execution  is 
therefore  a  novelty  of  this  report. 


7  Pragmatics 


The  given  typing,  data  access  specification  and  execution  semantics  for  MSR  provide  a  foundation  for  proving  useful  proper¬ 
ties  about  this  language,  as  we  did  in  Section[6]  However,  they  are  not  optimal  either  in  terms  of  implementability  or  usability. 
In  this  section,  we  briefly  examine  three  pragmatic  enhancements,  none  of  which  is  a  prerequisite  for  or  otherwise  impacts  the 


validity  of  the  results  examined  in  this  document.  In  Section  7.1  we  discuss  opportunities  for  type  reconstruction  and  outline 


an  approach  to  realizing  it.  In  Section  7.2  we  examine  the  basis  for  an  implementation  strategy  that  relies  on  matching  for 
selecting  appropriate  terms  to  instantiate  universal  variables  with.  Finally,  we  present  a  simple  check  that  verifies  that  an 


active  role  set  effectively  came  from  the  protocol  theory  at  hand  in  Section  7.3 
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7.1  Type  Reconstruction 

Each  constant  occurring  in  an  MSR  protocol  is  to  be  interpreted  as  having  been  introduced  by  a  declaration  in  a  dependent 
prefix,  or  in  a  role  (as  the  leading  V  or  through  3),  or  inside  the  rule  itself  as  a  V  or  3  declaration.  As  a  matter  of  readability, 
convenience  to  the  user  and  usability,  a  number  of  declarations  and  typing  information  can  be  omitted  and  automatically 
reconstmcted  from  the  context  in  which  variables  are  used  and  from  a  limited  number  of  type  declarations.  An  MSR  imple¬ 
mentation  is  expected  to  either  reconstruct  this  omitted  data,  when  this  can  be  done  unambiguously,  or  issue  detailed  error 
messages  so  that  the  user  can  add  sufficient  text  to  help  reconstruct  the  remaining  omitted  parts.  We  will  now  examine  these 
opportunities  in  more  detail,  although  we  will  not  display  rules  to  achieve  this.  A  detailed  account  of  type  reconstruction  in 
the  presence  of  dependent  types  can  be  found  in  (56). 

The  acceptable  omissions  fall  into  the  following  two  classes: 

•  Implicit  bindings  comprise  the  V  declarations  at  the  head  of  a  rule  and  the  dependent  prefixes  of  a  type  or  subtype. 

•  Type  part  of  a  declaration. 

The  omitted  dependent  prefixes  of  a  type  declaration  also  lead  to  the  omission  of  the  corresponding  parameters  when  these 
symbols  are  used. 

Reconstruction  of  Universal  Bindings 

The  binders  Va;  :  r  occurring  in  a  rule  can  be  omitted  as  long  as  the  variable  x  is  not  explicitly  bound  by  another  declaration 
and  the  type  r  can  be  reconstructed.  Upon  encountering  an  undeclared  symbol  x,  the  compiler  shall  extend  the  rule  it  occurs  in 
with  the  prefix  Va;  (the  still  implicit  type  is  reconstructed  at  a  later  stage,  or  a  type  variable  a,  to  be  instantiated  subsequently, 
can  be  inserted). 

The  reconstruction  algorithms  outlined  in  this  section  apply  only  within  a  rule,  and  not  elsewhere.  It  shall  also  be  noted 
that,  in  general,  this  simple  syntactic  binder  reconstruction  needs  to  be  alternated  with  the  more  complex  reconstruction  of 
omitted  types,  as  an  omitted  type  may  make  use  of  a  yet  undeclared  variable. 

Reconstruction  of  Dependent  Prefixes 

Every  symbols  occurring  in  a  base  type  should  be  declared  before  its  first  use.  However,  since  many  of  these  declarations  are 
bookkeeping  dependent  prefixes  of  the  type  or  subtype  they  appear  in,  it  is  convenient  to  omit  them  whenever  they  can  be 
reconstmcted.  We  adopt  the  same  strategy  as  in  the  case  of  omitted  ix  :  r  declarations.  The  missing  dependent  type  binder 
for  symbol  x  is  added  at  the  front  of  the  type  or  subtype  as  an  object  declaration  with  its  type  temporarily  expressed  as 
the  type  variable  a.  If  only  the  variable  declaration  (but  not  the  type  or  subtype)  has  been  omitted,  we  extend  a  type  r  into 
and  a  subtype  a  into  a^x\ 

Whenever  an  undeclared  symbol  occurs  in  a  type  within  a  mle,  it  may  need  to  be  expanded  as  either  a  V  declaration  or  a 
dependent  prefix.  In  general,  the  latter  is  preferred  if  it  occurs  within  a  single  type  after  all  the  reconstruction  steps  have  been 
performed.  A  V  declaration  is  necessary  only  when  this  symbol  occurs  in  two  different  types.  Other  considerations  are  as  in 
the  case  of  implicit  V  declarations. 

Reconstruction  of  Omitted  Types 

Object  declarations  “x  :  r”  can  be  abbreviated  as  “x”  whenever  the  type  r  can  be  reconstructed  from  the  context.  Type 
reconstmction  information  are  obtained  from  the  following  sources: 

Previous  declarations.  For  example,  if  a  signature  contains  a  declaration  /  :  t  — >  t'  for  a  function  symbol  /,  and  a  type 
Jx>  x  (. . .  fx  . . .)  where  the  type  of  x  has  been  omitted  as  _,  then  it  can  be  deduced  that  the  type  of  x  shall  be  r. 

Data  Access  Specification  information.  Data  access  information  imposes  constraints  on  the  identity  of  principals  or  the 
ownership  of  keys.  Often  times,  only  one  value  allows  a  rule  to  pass  the  data  access  specification  test.  In  these  cases, 
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it  is  admissible  to  omit  typing  information,  even  if  reconstruction  by  the  sole  means  of  the  surrounding  declarations  is 
not  possible. 

Type  reconstruction  is  usually  done  by  inserting  type  variables  in  place  of  the  omitted  types,  and  collecting  and  propagating 
constraints  until  a  single  solution  emerges  (success),  the  constraints  are  found  to  be  inconsistent  (fatal  error),  or  all  possible 
constraint  simplifications  have  been  attempted  but  constraints  remain  (underspecification  error).  In  the  latter  case,  the  author 
of  the  specification  shall  be  invited  to  add  typing  information  and  run  the  checker  again. 

Subtypes 

Whenever  a  type  subject  to  reconstruction  belongs  to  a  subtype  hierarchy,  the  result  shall  be  the  lower  bound  of  all  types 
occurring  in  the  constraints,  subject  to  the  usual  variance  and  contravariance  conditions.  For  example,  given  a  subtype 
declaration  r  ::  r'  and  a  variable  whose  type  can  be  reconstructed  as  either  r  or  t' ,  t  shall  be  preferred.  If  this  lower  bound 
is  not  unique,  then  an  underspecification  error  shall  be  returned. 

Implicit  Arguments 

Whenever  an  identifier  declaration  relies  on  omitted  typing  information,  any  use  of  this  identifier  shall  omit  all  arguments 
corresponding  to  this  omitted  typing  information.  For  example,  if  c  is  declared  of  type  a  x  (by  means  of  the  declaration 
c  :  a  x)  where  the  type  of  x  is  kept  implicit,  then  every  use  of  c  shall  take  the  form  c  t  for  term  t  of  type  a  t'  for  an  appropriate 
term  t! .  If  instead  c  is  declared  of  type  t^x )  x  a  x  (by  means  of  the  declaration  c  :  t<xI  x  a  x)  with  the  type  of  x  given 
explicitly,  then  every  use  of  c  can  only  be  of  the  form  c  (t' ,  t )  where  t'  has  type  r  and  t  has  type  a  t! . 

During  reconstruction,  these  omitted  arguments  shall  be  reconstructed  as  well. 


7.2  Lazy  instantiation 

In  Section[6]  the  execution  rules  concerning  a  universal  quantifier,  sex  all  and  sex  grole,  operate  by  guessing  an  appropriate 
term  t  or  principal  name  A  and  then  substituting  it  for  the  bound  variable.  This  is  clearly  not  an  effective  approach  to 
instantiating  universal  variables. 

In  logic  programming,  where  a  similar  form  of  instantiation  needs  to  be  performed  in  order  to  use  a  clause,  the  choice  of 
the  instantiating  term  is  delayed  until  later  execution  forces  it.  This  is  achieved  by  replacing  universally  quantified  variables 
with  logical  variables  when  rules  such  as  sex  all  and  sex  grole  are  encountered,  and  by  using  unification  to  instantiate  them 
when  the  execution  needs  to  commit  to  specific  terms  —  matching  is  sufficient  in  the  case  of  MSR.  Logical  variables  form  a 
new  syntactic  category  in  the  internal  language  used  during  execution.  They  are  defined  as  follows: 


Logical  variable:  X  ::= 


Each  logical  variable  X £  is  parametrized  by  its  expected  type,  r,  and  a  signature  E  that  lists  the  signature  constants  that  can 
legally  be  used  in  a  substitution  term  for  this  variable.  We  write  X  for  a  logical  variable  when  the  type  and  signature  are 
unimportant  or  can  easily  be  reconstructed  from  the  context.  Note  that  logical  variables  are  distinct  from  the  variables  we 
have  encountered  so  far. 

During  execution,  we  will  instantiate  logical  variables  to  ground  terms  by  matching  rule  left-hand  sides  (where  logical 
variables  may  occur)  with  states  (which  shall  be  ground).  A  successful  match  is  witnessed  by  a  substitution,  written  6,  which 
associates  each  logical  variable  in  the  rule  with  a  ground  term.  Applying  a  substitution  6  to  an  object  O  (a  term,  rule  fragment 
or  role)  produces  an  object  O'  where  each  logical  variable  mentioned  in  6  has  been  replaced  with  the  associated  ground  term. 
We  write  [0\O  for  this  operation. 

Given  these  premises,  the  following  rules  upgrade  the  operational  semantics  given  in  Section  [6] to  make  use  of  logical 
variables  and  matching.  For  convenience,  we  use  a  formulation  that  bypasses  the  rule  application  judgment  (see  the  proof  of 
Theorem|6.19|). 


■  sex_arole* 


(?,/)>  [S\ 


R 


[5] 


R,P 

E 


(V,(PYA)t>  [S]f 


^  R,lxg**/A](pA) 


■  sex_grole* 
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.  sex_rsp* 


rci  -R.d1-! !l\pY 

(S,L i:f) 


V>  [5]"l((Va!:T-r)-rt> 


^  R,(({X-/x]r),p)A 


_all* 


{[9]rhs)m s  >  (rhs')s' 


V>  [S,[0}lhs]*’ms^rhs)’p)A  — >  [S,rhs'}%mp)l6]A 


sex_core* 


v>  [5] 


R,(r,p)A 

s 


[s\ 


R,{p)a 

(S,L;:r) 


sex_skp* 


v>  [5] 


R,(-)a 

S 


- sex_dot* 

[s\2 


As  mentioned  earlier,  rules  sex_all*  and  sex_grole*,  which  handle  universal  quantifiers,  now  replace  the  bound  variables  with 
a  new  logical  variable  of  the  appropriate  type  and  in  the  current  signature.  The  interesting  action  takes  place  in  rule  sex_core*. 
The  rule  being  applied  has  the  form  Ihs  — >  rhs.  To  use  it,  we  check  if  the  current  state,  call  it  S*,  can  be  partitioned  into  a 
part  S  that  will  be  left  alone  and  a  part  S'  that  matches  Ihs  by  means  of  some  substitution  9,  i.e..  S'  =  [9]  Ihs.  If  so,  we  invoke 
the  right-hand  side  instantiation  judgment  on  the  corresponding  instantiation  of  rhs  and  of  the  signature  E,  thereby  obtaining 
some  partial  state  rhs'  and  updated  signature  S'.  We  then  replace  [6]  Ihs  in  S*  with  rhs ’  and  propagate  the  substitution  0 
to  the  remaining  rules  in  the  current  active  roles  set  and  to  the  role  owner.  Other  rules  do  not  change,  in  particular  logical 
variables  play  no  role  in  handling  existential  quantifiers. 

It  should  be  noted  that  a  signature  E  can  contain  logical  variables.  Moreover,  the  notation  (S',  [9\lhs)  calls  for  pattern 
matching  of  Ihs  with  the  state  at  hands,  which  will  yield  the  substitution  9.  Pattern  matching  is  done  using  standard  proce¬ 
dures,  but,  because  we  are  in  a  dependent  setting,  every  match  t  found  for  each  variable  should  be  type-checked  so  that 
E  h  t  :  t. 


7.3  Legal  Active  Roles 


As  we  saw,  a  snapshot  of  the  execution  of  a  protocol  theory  V  consists  of  a  state  S,  a  signature  E,  and  an  active  role  set  R.  A 
natural  question  to  answer  is  whether  R  is  actually  an  instance  of  V,  in  the  sense  described  above.  We  model  it  by  means  of 
the  judgments: 


E  h  V  <  pA 
E  h  p'a  <  pA 
£  h  p'  <  p 

r  h  9 


pA  stems  from  V  in  E 
pA  stems  from  p'a  in  E 
p  stems  from  p '  in  T 
9  is  well-formed  in  E 


The  first  simply  checks  that  active  role  set  element  pA  comes  from  protocol  theory  V  by  picking  an  appropriate  role  in  there. 
It  is  defined  by  the  following  two  rules: 


Ehp'</ 


Eh?</ 


E  h  (V,p')<pA 


E  h  (P,p')<pA 


The  second  judgment  makes  sure  that  the  owner  of  p  and  p'  corresponds.  This  is  achieved  through  instantiation  in  the  case  of 
a  generic  role,  as  expressed  by  the  following  rules. 


(E,  A  :  principal,  E')  h  [A/A]p'<p 
(E,  A  :  principal,  S')  h  (p')yA  <\  pA 


(E,  A  :  principal,  S')  h  p'  <  p 
(E,  A  :  principal,  S')  h  (p')A  <  pA 


The  bulk  of  the  work  is  done  by  the  third  judgment.  It  follows  the  structure  of  the  candidate  role  p'  by  inserting  quantified 
variables  in  the  context  and  possibly  skipping  rules  until  it  matches  the  target  role  p.  The  rightmost  rule  below  handles  this 
case  by  finding  an  appropriate  substitution  9  and  ensuring  that  \0\p'  coincides  with  p  up  to  the  renaming  of  bound  variables. 
This  is  expressed  by  the  premise  [9\p'  =a  p  —  we  do  not  show  the  rules  for  this  standard  notion. 

(T,  L  :  t)  h  p  <  p  (T,  x  :  r)  h  (r,  p)  <  p  T  h  p'<p  T  b  9  [9]p  =a  p 

T  h  (3 L  :  t.  p')  <3  p  T  h  ((Vx  :  r.  r),  p')  <a  p  T  b  (r,  p')  <3  p  T  h  p'  <3  p 
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The  judgment  T  b  6  appearing  in  the  premise  of  this  rule  checks  that  a  substitution  is  well-formed  in  a  signature.  It  is  defined 
as  follows: 

r  h  e  E  h  r  £  h  t  :  T  (£,L,  :  f,T)  I-  (9 

Eh-  (£,r,a:  :  r)  h  0,t/x  (£,  L,  :  r,  T,  L  :  f)  h  6,  U/L 

Notice  that  these  judgments  implement  a  necessary  condition  for  an  active  role  to  come  from  a  protocol  theory,  but  not  a 
sufficient  one  since  the  occurrence  constraints  on  fresh  data  placed  by  the  existential  quantifiers  may  not  be  met.  In  order  to 
guarantee  this,  we  would  essentially  need  to  undo  the  computation  from  the  target  state  to  an  initial  state. 


8  Intruder 


In  this  section,  we  turn  to  the  MSR  specification  of  a  potential  attacker,  against  which  we  may  want  to  analyze  a  given  protocol. 
We  start  in  Section [8d~| by  presenting  an  MSR  formalization  of  what  has  come  to  be  accepted  as  the  standard  abstraction  of 
the  attacker:  the  Dolev-Yao  intruder  1 52'  44j.  This  will  assume  the  form  of  a  suite  of  roles  anchored  on  a  specific  principal, 
the  intruder  that  we  denote  I,  that  altogether  capture  the  capabilities  usually  associated  with  this  attacker.  Our  strongly  typed 
framework  will  shed  some  light  on  what  these  capabilities  actually  are,  and  we  will  show  that  they  are  closely  related  to  the 
notion  of  data  access  specification  defined  in  Section [5]  Since  MSR  allows  expressing  the  intruder  as  any  other  role,  we  can 
write  arbitrary  complex  specifications  for  I.  In  Section  8.2  we  show  that  any  such  roles  can  be  emulated  by  the  protocol  suite 
introduced  in|8.1|  Therefore,  the  Dolev-Yao  intruder  is  the  most  powerful  attacker. 

It  will  be  convenient  to  format  roles  as  in  the  following  diagram: 


/ 


Role  State  Predicate  Parameter  Declarations 


\ 


Owner 


Universal 

Left-hand 

-> 

Existential 

Right-hand 

quantifiers 

side 

quantifiers 

side 

Second  rule 


V 


Last  rule 


The  header  lists  the  roles  state  predicate  declarations  used  by  the  role.  It  is  followed  by  the  rules  that  constitute  it  (we 
will  never  need  to  alternate  declarations  and  rules).  Each  rules  is  represented  by  the  four  blocks  in  the  diagram.  We  find 
it  convenient  to  list  their  element  in  columns.  Whenever  a  role  consists  of  more  than  one  rule,  the  universal  quantifier 
prefix  grows  monotonically  when  passing  from  one  rule  to  the  next.  We  acknowledge  this  fact  by  abbreviating  the  repeated 
quantifiers  as  “V . . .”.  Finally,  we  mark  types  that  can  be  reconstructed  from  the  other  information  present  in  a  rule  by 
denoting  them  in  a  shaded  font. 


8.1  The  Dolev-Yao  Intruder 

The  Dolev-Yao  abstraction  of  a  crypto-protocol  appears  to  be  drawn  from  positions  taken  in  l52l  and  from  a  simplified  model 
presented  in  l44ll.  It  assumes  that  such  elementary  data  as  principal  names,  keys  and  nonces  are  atomic  rather  than  strings 
of  bits,  as  implemented  in  practice.  Furthermore,  it  views  the  operations  needed  to  assemble  messages,  i.e.  concatenation, 
encryption  and  digital  signature,  as  pure  constructors  in  an  initial  algebra.  Therefore,  if  n  is  a  nonce  and  k  a  key,  { n }  /.  is 
a  composite  object  whose  structure  is  clearly  recognizable.  This  means  for  example  that  a  term  of  the  form  {!}&  cannot 


56 


8  INTRUDER 


be  mistaken  for  a  concatenation  (t\  £2)-  and  that  {£}/,.  =  {t'}k'  if  and  only  if  t  =  t'  and  k  =  k' .  This  also  means  that 
the  Dolev-Yao  model  abstracts  away  the  details  of  the  cryptographic  algorithms  in  use,  reducing  in  this  way  encryption  and 
decryption  to  atomic  operations.  Indeed,  it  is  often  said  to  adopt  a  black  box  view  on  cryptography. 

The  atomicity  and  initiality  of  the  Dolev-Yao  abstraction  limits  considerably  the  attacks  that  can  be  mounted  against 
a  protocol.  In  particular,  its  idealized  encryption  model  makes  it  immune  to  any  form  of  crypto-analysis:  keys  cannot  be 
exhaustively  searched,  piecewise  inferred  from  observed  traffic,  or  guessed  in  any  other  manner.  An  encrypted  message  can 
be  deciphered  only  when  in  possession  of  the  appropriate  key.  The  symbolic  nature  of  this  abstraction  allows  then  to  very 
precisely  circumscribe  the  operations  an  intruder  has  at  his  disposal  to  enact  an  attack  against  a  protocol.  All  together,  they 
define  what  has  become  to  be  known  as  the  Dolev-Yao  intruder.  This  attacker  can  do  any  combination  of  the  following  eight 
operations  that  we  find  convenient  to  organize  in  the  five  lines  below: 

•  Intercept  and  learn  messages  •  Transmit  known  messages 

•  Decompose  concatenated  messages  he  has  learned  •  Concatenate  known  messages 

•  Decipher  encrypted  messages  if  he  knows  the  keys  •  Encrypt  known  messages  with  known  keys 

•  Access  public  information 

•  Generate  fresh  data 

The  first  line  implies  that  the  Dolev-Yao  intruder  has  complete  control  of  the  network.  This  is  clearly  a  worst  case  scenario. 

MSR  is  a  clear  instance  of  the  the  Dolev-Yao  abstraction.  Elementary  data  are  indeed  atomic,  message  are  constructed 
by  applying  symbolic  operators,  and  the  criterion  for  identifying  terms  is  plain  syntactic  equality.  We  will  now  give  a 
specification  of  the  Dolev-Yao  intruder  in  MSR.  In  Section  [O]  we  give  an  encoding  of  an  optimized  version  of  this  attacker 
proposed  in  1(501  and  formalized  using  a  previous  version  of  MSR  in  l27l. 

It  has  been  proved  that  there  is  no  advantage  in  considering  more  than  one  Dolev-Yao  adversary  in  any  given  system  l(59l. 
Therefore,  we  select  a  principal,  I  say,  and  endow  it  with  the  powers  of  the  Dolev-Yao  intruder. 

Since  the  intruder  can  learn  and  manipulate  information,  he  must  be  able  to  store  data  out  of  sight  from  other  principals. 
This  is  easily  achieved  in  MSR  by  associating  I  with  a  memory  predicate  /  (_)  whose  single  argument  can  hold  a  message  (the 
subscript  “1”  is  kept  implicit).  The  standard  Dolev-Yao  intruder  signature  SDV  for  this  model  is  defined  as: 

TiDY  =  I  :  principal,  /(_)  :  principal  x  msg 

On  the  basis  of  this  declarations,  we  will  express  each  of  the  intruder’s  capabilities  as  one  or  more  roles  consisting  of  a 
single  rule.  We  give  them  a  name  (written  in  bold  to  its  left)  that  will  be  referred  to  in  Section  |8.2|  Each  of  these  roles 
will  be  anchored  at  I  and  altogether  model  the  actions  that  the  Dolev-Yao  intruder  can  undertake  to  mount  an  attack.  They 
constitute  the  standard  Dolev-Yao  intruder  theory  that  we  denote  Vnv.  Thus,  the  knowledge  of  the  intruder  is  represented  in 
a  distributed  fashion  as  a  collection  of  memory  predicates  of  the  form  /  (£)  for  all  known  terms  t. 

The  first  line  of  the  description  of  the  Dolev-Yao  intruder  is  then  expressed  by  the  following  two  roles,  anchored  on  I. 
The  rule  on  the  left  captures  a  network  message  l\l(£)  and  stores  its  contents  in  the  intruder’s  memory  predicate.  Observe 
that  the  execution  semantics  of  MSR  implies  that  l\l(f)  is  removed  from  the  current  state  and  therefore  this  message  is  not 
available  any  more  to  the  principal  it  was  supposed  to  reach.  The  rule  on  the  right  emits  a  memorized  message  out  in  the 
public  network. 

INT:  (Vf  :  msg.  N(£)  — ►  /(f))'  TRN:  (Vf  :  msg.  /(£)  — ►  l\l(£))' 

From  now  on,  we  will  only  be  concerned  with  the  memory  predicate  M|,  which  acts  as  a  workshop  where  the  intruder 
can  dismantle  intercepted  communications  and  counterfeit  messages.  Concatenated  messages  do  not  offer  any  barrier  to  the 
intruder:  he  can  take  them  apart  at  will.  Similarly  he  can  construct  the  concatenation  of  any  two  messages  he  knows.  This  is 
realized  by  the  following  two  rules: 

DCM:  ^V£i, £2  :  msg.  I(t1t2)  -A  /(£.!))  CMP:  fv£i,£2  :  msg.  -A  / (£1  £2) 
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The  third  line  of  the  specification  of  the  Dolev-Yao  intruder,  at  the  beginning  of  this  section,  states  that  I  must  know  the 
appropriate  decryption  keys  in  order  to  access  the  contents  of  an  encrypted  message.  Dually,  he  must  be  in  possess  of  the 
correct  key  in  order  to  perform  an  encryption.  The  following  two  rules  formalize  this  requirement  in  MSR  in  the  case  of 
shared-key  codings: 


(WA,  B  :  principal. 
Vfc  :  shK  A  B. 

Vi  :  msg. 


'({*}*) 

/(*) 


SEC: 


y A.  B  :  principal. 
Vfc  :  shK  A  B. 

Vi  :  msg. 


I(t) 

m 


i 


Both  for  taking  apart  and  constructing  a  shared-key  encrypted  message,  the  intruder  must  know  the  key.  Observe  that  most 
typing  information  can  be  inferred. 

The  treatment  of  public-key  cryptography  is  similar.  Notice  that  here  the  intruder  must  have  access  to  a  private  key  for 
decrypting,  while  the  public  key  is  sufficient  for  generating  encrypted  messages. 


N A  :  principal. 
Vfc:  pubK  A. 
Vfc'  :  privK  fc. 
\Vf  :  msg. 


mh) 

Z(fc') 


/(i) 

/ 


(VA  :  principal. 
Vfc  :  pubK  A. 
Vi  :  msg. 


/(i) 

/(fc) 


im k) 


We  now  tackle  the  often  overlooked  fourth  line  of  the  Dolev-Yao  intruder  specification  above:  the  ability  to  access  public 
information.  He  should  clearly  be  entitled  to  look  up  the  name  and  public  keys  of  principals,  but  any  attempted  access  to 
more  sensitive  information  such  as  private  keys  should  be  forbidden.  Our  data  access  specification  policy  already  enforces 
this  kind  of  requirements.  Therefore,  we  will  express  the  capabilities  of  the  intruder  with  respect  to  public  information  access 
by  means  of  the  strongest  rules  that  satisfy  our  data  access  specification  policy.  We  have  the  following  five  anchored  roles: 

IPR:  (yA  :  principal.  •  — >  / (^4)) 1 


(VA  :  principal. 
l^Vfc  :  shK  I  A. 


f\/A  :  principal. 
l^Vfc  :  shK  A  I. 


i 


A/A  :  principal. 
^Vfc  :  pubK  A. 


Vfc  :  pubK  I. 
Vfc'  :  privK  fc. 


i 


The  last  line  of  the  specification  of  the  Dolev-Yao  intruder  hints  at  the  fact  that  he  should  be  able  to  create  fresh  data.  We 
must  be  very  careful  when  implementing  this  requirement:  in  most  scenarios,  it  is  inappropriate  for  I  to  generate  a  shared  key 
k*  between  two  principals  A  and  B  since  this  would  result  in  unwanted  trivial  attacks  where  A  and  B  use  k*  instead  of  their 
legitimate  shared  key  kAB  (this  would  be  very  close  to  permitting  the  intruder  to  guess  keys).  In  general,  we  do  not  allow 
the  intruder  to  generate  keys.  Similarly,  the  adversary  should  not  be  entitled  to  create  new  principals.  Nonces  and  atomic 
messages  are  instead  risk-frees.  Therefore,  we  propose  the  following  two  rules: 

GNC:  (  •  — ►  3n  :  nonce,  /(n))1  GMS:  (  •  — ►  3m  :  msg.  /(m))1 

Observe  that  the  rationale  behind  these  two  rules,  although  reasonable,  may  conflict  with  idiosyncrasies  of  individual  proto¬ 
cols.  For  example,  the  full  version  of  the  Needham-Schroeder  protocol  discussed  in  Section  [9. 1.2| may  be  more  accurately 
validated  in  the  presence  of  an  intruder  who  can  create  public  keys  (but  not  the  corresponding  private  keys). 

Last,  we  provide  our  formalization  of  the  Dolev-Yao  intruder  with  two  administrative  rules  to  allow  it  to  take  full  advan¬ 
tage  of  the  above  stated  capabilities.  The  rule  below  on  the  left  allows  it  to  forget  information.  The  more  interesting  rule  on 
the  right  permits  duplicating  and  reusing  fabricated  data. 

DEL:  (Vf  :  msg.  /(f)  ->  •)'  DUP: 

This  concludes  the  MSR  formalization  of  the  Dolev-Yao  intruder.  A  few  aspects  of  this  encoding  deserve  to  be  empha¬ 
sized: 


Vf  :  msg.  /(f) 


/(f) 

/(f) 
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1.  This  specification  lies  completely  within  MSR  and  can  therefore  be  adapted,  were  the  protocol  at  hand  require  it.  This 
differs  from  many  specification  languages  which  either  hardwire  the  intruder,  or  express  it  in  a  language  different  from 
the  protocol  under  examination.  It  should  be  observed  that  our  previous  version  of  MSR  belonged  to  this  latter  class: 
although  the  specification  of  the  intruder  was  subject  to  the  same  execution  semantics  as  the  other  roles,  it  relied  on  a 
slightly  different  language. 

2.  Typing  allows  a  very  precise  characterization  of  what  the  intruder’s  capabilities  actually  are.  This  is  clearly  manifested 
in  the  rule  clusters  that  formalize  access  to  public  information  and  fresh  data  generation. 

3.  All  but  the  fresh  data  generation  rules  can  be  automatically  generated  from  the  term  language,  and  their  typing  and  data 
access  specification  rules. 

It  is  easy  to  verify  that  the  above  MSR  formalization  of  the  Dolev-Yao  intruder  is  well-typed  and  satisfies  data  access 
specification: 


Property  8.1  ( Typing  and  Data  Access  Specification  Validity  of  the  Dolev-Yao  Model) 

Let  EDy  and  VDY  be  the  signature  and  protocol  theory  for  the  Dolev-Yao  intruder.  Then,  the  judgments 


I-  T,dy 


i-  vDY 


2 DY  II"  Vdy 


are  derivable. 

Proof:  We  omit  this  easy  inspection.  □ 

The  validation  of  the  judgment  “EJJV  lb  V  ,,Y”  makes  use  of  all  the  data  access  specification  rules  in  Section[5]  except 
the  ones  dealing  with  role  state  predicates. 

8.2  The  Most  Powerful  Attacker 

The  Dolev-Yao  intruder  is  by  no  means  the  only  way  to  specify  a  protocol  adversary.  Indeed,  MSR  allows  writing  attacker 
theories  of  much  greater  complexity  by  using  multi-rule  roles,  branching,  long  predicate  sequences,  diversified  memory 
predicates,  and  deep  pattern-matching.  It  is  however  commonly  believed  that  any  attack  mounted  by  such  an  attacker  can  be 
uncovered  by  using  the  Dolev-Yao  intruder.  The  assumption  that  the  Dolev-Yao  intruder  subsumes  any  other  adversary  that 
plays  by  the  rules  of  the  Dolev-Yao  abstraction  is  built  into  the  most  successful  security  protocol  verification  systems  m 
mum  EH  El  EH  ED.  To  our  knowledge  and  from  discussions  with  several  security  experts,  it  appears  that  this  strongly 
held  belief  has  never  been  proved.  This  is  worrisome  considering  the  seldom-acknowledged  subtleties  that  our  formalization 
of  the  Dolev-Yao  intruder  has  exposed  in  Section  [8~i~|  Our  precise  definition  of  data  access  specification  and  the  fact  that  an 
attacker  is  specified  within  MSR  as  any  other  protocol  fragment  give  us  the  means  to  phrase  that  question  and  to  formally 
prove  that  it  has  a  positive  answer.  We  dedicate  this  section  to  this  task. 

Again,  let  I  be  the  intruder  (we  will  consider  situations  involving  multiple  intruders  at  the  end  of  this  section).  Assume  that 
we  are  given  a  derivation  of  a  generic  well-typed  and  data  access  specification  valid  execution  judgment  .(j  — >*  [S"]  . 

Clearly,  V,  R  and  R'  can  mention  arbitrary  (active)  roles  anchored  on  the  intruder.  Similarly,  S  and  S'  can  contain  role  state 
and  memory  predicates  belonging  to  I.  We  will  show  that  we  can  construct  an  encoding  r  for  the  entities  appearing  in 
that  judgment  such  that:  1)  rV~',  rR~1  and  rRn  do  not  mention  any  intruder  specification  beyond  VnY\  2)  r.S'~  and  rS'~' 
do  not  contain  any  role  state  predicate  for  I  nor  any  intruder  memory  predicate  except  at  most  /(_);  and  3)  the  judgment 
rVn,VDY  >  — >*  [r5"n]  rpn  is  derivable. 
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8.2.1  Encoding  Protocol  Theories,  States,  and  Signatures 

The  encoding  r'P~  of  a  protocol  theory  V  implements  the  idea  that  every  role  anchored  on  the  intruder  can  be  emulated  by 
means  of  VDY.  Therefore,  we  simply  filter  out  every  component  of  the  form  (p)1: 

-  r.n 

rr,  ( P)VA -1 

rv,  ( P 


=  r^n,  (p) 


VA 


(P)A 

r-pi 


if  A  ^  i 
otherwise 


The  Dolev-Yao  intruder  model  does  not  refer  to  any  role  state  or  memory  predicate  beside  /(_).  Whenever  one  of  these 
objects  appears  in  a  state  S,  the  encoding  r.S'n  will  account  for  it  by  including  one  instance  of  the  Dolev-Yao  intruder  memory 
predicate  /  (_)  for  each  of  its  arguments,  as  specified  by  the  following  definition: 


r.n 


rS,,N(f)“l  =  r 

Sn,N(t) 

rs,  m  A(ty  =  < 

frsn, 

lrSn, 

rtn 

Ma  (t) 

if  A  =  1 

otherwise 

where 

r 

L 

II  II 

r 

r 

L*  L 

1 _ 1 

rs,  U(A,ty  =  < 

frsn, 

Lr5n, 

rA,tn 

Lz  (A  ,t) 

if  A  =  i 

otherwise 

The  encoding  of  a  signature  E  is  obtained  by  including  any  part  of  the  Dolev-Yao  intruder  signature  EJ)y  that  may  be 
missing.  We  highlight  this  fact  by  writing  rEn  as  E  ©  T,DY,  which  is  defined  as  E  \  (E  n  EDy)  U  Em-.  The  target  signature 
S'  of  an  execution  judgment  may  contain  role  state  predicate  symbol  declarations  introduced  by  the  execution  of  a  (non 
Dolev-Yao)  attacker  role.  We  shall  remove  them  from  the  translation,  as  indicated  in  the  statement  of  Theorem|8.17| 

While  the  above  entities  can  be  given  an  encoding  based  exclusively  on  their  structure,  this  approach  does  not  work 
smoothly  for  active  role  sets.  Attacker  rules  are  problematic:  clearly,  we  want  to  map  their  operations  to  Dolev-Yao  intruder 
roles,  but  the  direct  realization  of  this  idea  requires  a  wider  context  than  what  offered  by  a  simple-minded  recursive  definition. 
For  example,  upon  encountering  a  term  in  an  incoming  message,  we  may  or  may  not  need  to  use  one  of  the  shared-key 
roles  IS1  and  IS2  to  look  up  k.  Furthermore,  it  is  not  clear  whether  a  copy  of  k  is  needed  in  other  parts  of  the  rule. 


If  we  only  consider  entities  that  satisfy  the  typing  and  data  access  specification  restrictions,  we  can  circumvent  this 
difficulty  by  basing  the  encoding  of  an  active  role  set  R  on  a  derivation  A  of  the  data  access  specification  judgment  E  lb  R, 
for  a  given  signature  E.  Indeed,  A  would  specify  how  the  key  k  in  the  above  example  is  accessed,  and  indirectly  how  many 
times  it  is  needed  in  the  rule  it  appears  in.  The  next  three  sections  show  how  this  is  achieved.  They  show  how  to  determine 
a  specific  set  r A~  of  Dolev-Yao  intruder  roles  from  any  given  derivation  A  of  E  lb  R.  It  does  so  by  mapping  each  rule 
instance  occurring  in  A  to  zero  or  more  intruder  roles  from  Section  8.1  We  then  define  r  I A  as  rA~l.  This  definition  entails 
that  the  encoding  of  any  active  role  anchored  on  I  consists  exclusively  of  Dolev-Yao  roles  from  VDY. 


8.2.2  Dolev-Yao  Emulation  of  the  Antecedent  of  a  Rule 

We  begin  by  compiling  the  list  of  Dolev-Yao  rules  needed  to  emulate  the  actions  performed  in  the  right-hand  side  of  a  fully 
instantiated  rule  for  a  generic  intruder.  For  each  relevant  data  access  specification  judgment,  we  draw  a  table  that  associates 
each  rule  instance  (in  the  left  column)  to  the  roles  in  Efly  that  will  emulate  it  in  our  encoding.  We  will  be  using  the  same 
device  in  the  next  two  sections. 

We  begin  with  the  judgment  T;  A  IP A  k  A>  A'  that  manages  public  keys.  Its  four  rules  yield  the  following  table. 
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- kac_pss 

(r,  k  :  pubK  B,  U,  k'  :  privK  k,  T");  (A.  k,  k ')  \PA  k  >  (A,  k,  k') 

DUP 

-  kac.pus 

(r,  k  :  pubK  B,  U,  k'  :  privK  k,  T");  (A,  k')  IPA  k  >  (A,  k,  k') 

DUP 

-  kac_psu 

(r,  k  :  pubK  A,  r ' ,k'  :  privK  k,  T");  (A,  k)  IPA  k  >  (A,  k,  k') 

IPB,  IPV 

- kac.puu 

(r,  k  :  pubK  A,  r',  k'  :  privK  k,  T");  A  IPA  k  >  (A,  k') 

IPV,  DUP 

Before  we  can  prove  that  the  encoding  given  by  the  Dolev-Yao  rules  on  the  right-hand  column  can  emulate  the  left-hand 
side  decryption  actions,  we  need  to  provide  an  encoding  r  An  of  the  intruder  knowledge  A.  We  do  so  by  simply  embedding 
every  item  in  it  into  the  memory  predicate  /(_). 


r.~i  _ 

rA,f  =  rAn,  /(f) 

The  desired  correctness  lemma  is  then  as  follows. 


Lemma  8.2  (Dolev-Yao  Emulation  of  Public-Key  Decryptability) 

Let  E  =  (Si,  k  :  pubK  A ,  E2,  k'  :  privK  k,  E3)  be  a  signature  with  A  a  principal  name,  k  and  k'  keys,  and  Sp  S2  and 
E3  signature  fragments.  Let  moreover  A  and  A'  be  knowledge  contexts  compatible  with  E. 

If  A::  S;A  11“  fc»A',  then  ■>  fAl^v  [rA'V(£0]  e®e^- 


Proof:  The  proof  proceeds  by  induction  on  the  structure  of  A.  There  are  two  cases  to  examine: 


kac_puu 


A  = 


(E i,k  :  pubK  B ,  S2,  k'  :  privK  k,  E3);  A  IPA  k  (A,  k') 
with  A'  =  (A,  k').  Recall  that  rA n  =  (IPV,  DUP). 

■>  rA-isr  - 

>  lr^&kJ''DUP  — ^  [rA A/(fc')]fcP 

[rA-,/(fc')]E®ED. 


So 

£i 
£ 2 
£3 
£4 

£3 

£ 


■>  rA"1)  l(k')}  e®EdP 


■>  rA-,/(fcO]L®E)Dt(fc'y(fe'))l 


■>  [rAn,  l(k'),l(k')]  2®e 

ri_  .  IPV, I 

1  >  [  A  ] £®e 


IPV, DUP 

DY 


DY 

*  rr 


>  fA -,/(fc'),/(fc')]^®E 

An,  !{k'),  l(k')\  S0Sr)1, 


A,_l,  !(k')]  S0El 


kac_puu 


by  rule  sex_all  on  IPV, 
by  rules  sex_seq  and  seq_core, 
by  rule  sex_dot. 
by  rule  sex_all  on  DUP, 
by  rules  sex  seq  and  sex  core, 
by  rule  sex  dot,. 

by  rules  sex_itO  and  sex_itn  on  £q-£§. 


Rule  kac_pus  is  processed  in  a  similar  but  simpler  way.  □ 


The  use  of  shared  key  encryption  in  the  antecedent  of  a  rule  is  handled  similarly.  The  relevant  rules  and  their  encoding  is 
as  follows: 
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They  yield  the  following  emulation  lemma. 

Lemma  8.3  ( Dolev-Yao  Emulation  of  Shared-Key  Decryptability) 

Let  E  be  a  signature,  k  a  key,  and  A  and  A1  be  knowledge  contexts  compatible  with  E. 

If  *4  ::  E;  A  IP,  k  »  A',  then  •>  s&w  ~ [rA^, /(*)] 

Proof:  The  proof  proceeds  by  induction  on  yl  similarly  to  the  public-key  variant  of  this  property  (Lemma[8.2|>.  □ 


The  encoding  of  the  left-hand  side  term  decomposition  judgment  T;  A  h,  t  >  A'  is  given  by  the  following  table. 


- tac_dot 

r;  a  ibA  •  »  a 

r;(A,e)  lbA  r»  A'  r;(A,t)  n-A  f »  A' 

- tac_kn  - tac_kn* 

r;  ( A,  e)  Ihi  e,  t  >  A'  T;  (A,  t)  lb,  t,  f  >  A' 

DEL 

(r,e  :  r,r');(A,e)  lhA  t  >  A' 

- tacukn 

(r,e:r,r');A  lbA  e,f»  A' 

r ;  A  Ibt  A' 

- tac.cnc 

r ;  A  IhA  (ii  A' 

DCM 

r;Aiiajlfc>A'  r;A'  IhA  t,t>  A" 

- tac_ske 

r;  a  ihA  a" 

SDC 

r;AlP4fc>A'  r;A'  IHa  t,?>  A" 

- tac_pke 

r;  a  ibi  a" 

PDC 

The  following  lemma  ascertains  the  correctness  of  the  emulation. 


Lemma  8.4  ( Dolev-Yao  Emulation  of  Term  Decomposability) 

Let  E  be  a  signature,  t  a  term  tuple,  and  A  and  A'  be  knowledge  contexts  compatible  with  E. 
If  -4  ::  S;  A  lb,  t  »  A',  then  ■>  fA  — ►*  [rAn]seEijy. 


Proof:  The  proof  proceeds  by  induction  on  the  structure  of  A.  We  will  expand  the  cases  of  rule  tac_kn  and  tac_ske,  which 
rely  on  techniques  that  have  not  yet  been  used. 


A\ 

E;  (A*,  e)  U-A  t'  >  A' 

A  =  - tac_kn 

E;(A*,e)  U-A  e,t'  >  A' 
with  A  =  (A*,e)  and  t  =  (e,  t').  Recall  that  rA~1  =  (r.4i_\  DEL). 


tac_kn 


£o  ::  ■>  [rA*V(e),rr'^Xr 


"A' 


I  sesi 


by  induction  hypothesis  on  A i, 


ft  "  ■>  rA*-',/(e),/(c)>rn^;D“  — ►*  fA^J(e)^t'f 

£  ::  •>  fA  -,/(e),/(e),rfn]^,r  _+*  [rA^]  S0Edv 


rf,nl  s®iDY  by  using  role  DEL,  i. e.  by  rules  sex_all, 
sex_seq,  sex_core  on  DEL,  and  then 
sex_itn. 


by  the  Chaining  Lemma  6.1  on  £q-£\. 
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tac_ske 


A  = 


Ai  A-2 

E;  A  IPA  k  »  A'  E;  A'  lhA  t,  t'  >  A" 

S;  A  \bA  {t}k,t'  >  A" 


-  tac_kn 


J  S©S£)y 

•>  fA 


with  t=  ( { ^ }  fe ,  )  •  Recall  that  rA~l  =  (' ~Ai~*,  rA2~',  SDC). 

rrA^:ic  — ►*  [rA'v(fc)]£®SDy 

rAl~l,rA2~l,  SDC 

An,rtnJ({t}k),  l(k)]  S0S 

FAn,r?n,mr£i 

[rA"n]  S0SDy 

[rA"n]  £©EDr 


f' 

c0 


£1 

£ 


DY 

w*  n~, 


■>fA  n,r^i{{th),m]r^^° 


rA2n,SDC 
DY 

A2' 


■>  [rA'Vr'V(i)]Etiw  - 

]  rAi~',rA2~',snc 

E DY 


■>  rA -,rPM({t}k)irsi£ 


by  using  role  SDC, 

by  induction  hypothesis  on  A 2, 

by  the  Chaining  Lemma  6.1  on  £{)-&>,. 


The  other  rules  are  handled  similarly.  □ 


The  knowledge  merging  judgment  A  >  t  >  A' is  translated  as  per  the  following  table. 


The  corresponding  correctness  lemma  is  as  follows. 


Lemma  8.5  (Dolev-Yao  Emulation  of  Knowledge  Merging ) 


Let  E  be  a  signature,  e  a  term  tuple,  and  A  and  A7  be  knowledge  contexts  compatible  with  E. 
If  A::  A  >  e  >  A'  then  •>  f  AVeT]  — ►*  [rA^]S0Iw. 


Proof:  The  proof  proceeds  again  by  induction  on  the  structure  of  A.  Rules  mac  ukn  and  mac  kn  make  use  of  the  Execution 
Weakening  Lemma  6.4  □ 


Finally,  we  have  the  following  translation  of  the  data  access  specification  rules  for  the  left-hand  side  of  an  MSR  rule. 
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A  >  (A,  e)  >  A'  r;  A'  lbA  Ihs  >  P  >  A" 

-  lac_rsp 

r;  A  lhA  L(A,  e ),  Ihs  >  t‘ '  >  A" 

A  >  (A,t)  >  A'  r;  A'  lhA  Ihs  >  t'  >  A"  A  >  (A,t)  >  A'  T;  A'  lhA  Ihs  >  F  >  A" 

r;  A  lhA  L(A,  t),  Ihs  >  P  >  A"  r;  A  lhA  L  t(A,  t),  Ihs  >  P  >  A" 

r;  A  lhA  Ihs  >  (t,P)  >  A" 

- lacnet 

T;A  lhA  N (t),lhs  >P  >  A" 

INT 

r;  A  lhA  Ihs  >  (t,  P)  >  A' 

- lac.mem 

r;  A  lhA  M  4 (F) ,  Ihs  >  P  »  A' 

r;  a  ihA  F»  A' 

-  lac_dot 

r ;  A  lbA  •  >  F>  A' 

In  order  to  state  and  prove  their  correctness,  we  need  to  define  the  encoding  rlhs 1  of  a  rule  antecedent  Ihs.  It  leaves 
network  predicates  intact,  but  translates  local  and  global  memory  predicates  into  the  intruder  predicate  /(_)  (see  earlier  for 
the  definition  of  rP). 

r.n  =  . 


r 


r 


r 


ihs,N(ty 

=  rlhs~l,  N(f) 

lhs,Mfty 

=  rlhsn,  rt^ 

Ihs ,  P(f*)n 

=  rlhs n,  rtn 

We  are  now  in  a  position  to  ascertain  that  the  antecedent  of  an  arbitrary  intruder  rule  with  a  valid  data  access  specification 
derivation  behaves  correctly. 


Lemma  8.6  (Dolev-Yao  Emulation  of  Left-Hand  Side  Decomposability) 

Let  E  be  a  signature,  Uis  a  predicate  sequence,  t  a  term  tuple,  and  A  and  A'  be  knowledge  contexts  compatible  with  E. 


If  _A::E;A  It-,  Ihs  >  t  A1,  then  •>  [rAn,  rlhs~',  rt  n] 


EffiEi 


“A'-1] 


£®£i 


Proof:  The  proof  proceeds  by  induction  on  the  structure  of  A.  It  uses  the  techniques  already  deployed  for  proving  Lemma|8~4| 
Rules  lac_mem  and  lac_dot  simply  rely  on  the  induction  hypothesis  and  the  definition  of  rlhs~l  above.  Rule  lac_net  addi¬ 


tionally  fires  role  INT.  Finally,  rule  lac_rsp  chains  a  use  of  Lemma  8.5  and  an  appeal  to  the  induction  hypothesis,  as  in  the 
case  of  rule  kac  ske  in  Lemma [84l  □ 


8.2.3  Dolev-Yao  Emulation  of  the  Consequent  of  a  Rule 

We  now  turn  to  the  emulation  of  the  right-hand  side  of  an  arbitrary  intruder  rule  on  the  basis  of  Dolev-Yao  rules.  We  start 
from  the  judgment  T  S->A  e  that  captures  access  to  elementary  information. 
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eac  pr 

(r,  e  :  principal,  r;)  S->a  e 

IPR 

- eac_sl 

(r,e  :  shK  A  B,  T')  S®a  e 

IS1 

- eac_s2 

(r,e  :  shK  B  A,  T')  ©>a  e 

IS2 

eac  pp 

(r,  e  :  privK  k,  T' ,  k  :  pubK  A,  T")  e 

IPV 

eac  p 

(r,e  :  pubKB.r')  e 

IPB 

The  correctness  of  this  encoding  is  given  by  the  following  lemma. 

Lemma  8.7  (Dolev-Yao  Emulation  of  Elementary  Information  Access  on  the  Right-Hand  Side) 

Let  E  be  a  signature  and  e  an  elementary  term.  If  A  ::  E  S®,  e,  then  •  >  [•]  s'® E „  Y  — [re_l]  e®edv' 

Proof:  This  proof  proceeds  by  cases  on  the  structure  of  A.  It  relies  on  the  techniques  already  seen  in  the  proof  of  LemmajiOj 
and  on  the  implicit  assumption  that  all  the  objects  in  A  are  well-typed.  □ 

In  most  of  the  rest  of  this  section,  we  will  need  to  simulate  the  deletion  and  duplication  of  the  entire  knowledge  context 
A.  The  operations  DEL(A)  and  DUP(A)  achieve  this  effect.  They  are  defined  as  follows: 

DEL(-)  =  •  DUP(-)  =  • 

DEL(A, t)  =  DEL(A),  DEL  DUP(A,f)  =  DUP(A),  DUP 

The  following  lemmas  ascertains  that  they  actually  work  as  expected.  Given  A,  picking  DEL(A)  as  our  active  role  set 
consisting  of  returns  an  empty  state,  while  using  DUP(A)  yields  a  state  with  two  copies  of  A. 

Lemma  8.8  ( Dolev-Yao  Emulation  of  Knowledge  Deletion  and  Duplication) 

Let  E  be  a  signature  and  A  a  knowledge  context  compatible  with  E. 

1  ■  ’  >  [r^n]E®EL')  [']s©Em-; 

2.  rA-'ffi?  ->*  rAVA-]Ee5W. 

Proof:  In  both  parts  of  this  property,  the  proof  proceeds  by  induction  on  the  structure  of  the  knowledge  context  A.  □ 

The  term  constructability  judgment  T ;  A  rK,  e  is  emulated  according  to  the  following  table. 


-  cac_kn  - cac_kn* 

T;  (A,  e)  e  T;  (A ,t)^>A  t 

DEL(A) 

r^A  e 

- cacukn 

T;  A  e 

DEL(A) 

T;  A  ^  ti  T;  A  q-*A  t2 

-  cac.cnc 

r ;  A  tl  t2 

DUP(A),  CMP 

r;  A  ^A  t  r;  A  q-»A  fc 

- cac_ske 

r-,A^A  {t}k 

DUP(A).  SEC 

T;  A  t  T;  A  q®,  k 

- cac.pke 

T;  A  S ->a 

DUP(A),  PEC 
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The  following  lemma  shows  that  this  translation  is  indeed  correct. 


Lemma  8.9  ( Dolev-Yao  Emulation  of  Term  Constructability) 

Let  S  be  a  signature,  A  a  knowledge  context  compatible  with  S,  and  t  a  term.  If  A  ::  S;  A  CH|  t,  then 
rA“n  r-4n 


J  -  [/(*)]  SSEdy’ 

Proof:  This  proof  proceeds  again  by  induction  on  the  structure  of  A.  We  will  examine  two  of  the  most  significant  cases. 

A\ 

S  ‘Hi  e 

A  —  -  cac_ukn 


cac_ukn 


S;  A  e 

with  t  =  e.  Recall  that  rA~*  =  rAi~l,  DEL(A). 

£0  ::  ■>  fA-]™/^  — 


ft 

£ 


iMC 
I  S©E£)y 


[/(e)] ; 


^  lJE®EDy  7  L  V'/i  E0Eny 

■>  rA"]^(:r^n  -+*  [/(e)], 


sesz 


by  Lemmas  8.8  on  A  and  then  the  Weakening  Lemma  6.4 


by  the  Access  Lemma  8.7  on  Ai, 


by  the  Chaining  Lemma  6.1  on  £q—£\. 


At 


Ao 


I  cac  cnc  A  = 


cac_cnc 


with  t  =  ti  t<z 


f' 

co 

So 

f 

ci 

ft 

S'* 
£ 2 
£.3 
£ 


A  S->4  1 1  T;  A  £2 

T;  A  S->A  £1  £2 

.  Recall  that  rA^  =  rA1~l,  rA2~l,  DUP(A),  CMP. 

[rAVA-]E0EDy 


.  c  rrA-ilDUP(A) 

l  J  E©S OY  L  '  J  ^W-^DY 

•>  [rA1^Cr4lV42l’CMP  — >*  [rAn,  rAn] 

'  >  [rAn]  E®EDy  [/(*!)]  S©SDy 

•t>  [rAn,  rAn]  j'0S2^2"l,OMP  ->*  [/ (f  1)1  rAn]  e®sd°MP 


by  the  Duplication  Lemmas 
by  the  Weakening  Lemma 


8.8 


on  A 


6.4 


on  £L 


by  induction  hypothesis  on  At , 


frA“ 


-  L  —  Je©i :Dy  **  [/(i2)]s©E DY 

•>  [/ (h),  rAn]  — ►*  [l(h),l(h)]^DY 

■>  [/(£l),  / (£2)]  e©Sdf  [/ (£1  £2)]  E©£Dy 
■>  rA-']^WW-OMP  -+*  [/(/i/2)]e®e 


by  the  Weakening  Lemma  6.4  on  £[, 

on  £. 2 , 


by  induction  hypothesis  on  A2, 
by  the  Weakening  Lemma  ( 
by  using  of  role  CMP, 
by  the  Chaining  Lemma  6.1  on  £ij-£:>. 


The  other  possibilities  are  treated  similarly  □ 


This  translation  is  trivially  extended  to  the  term  tuple  constructability  judgment.  It  is  formally  defined  next  and  followed 
by  a  proof  of  its  correctness. 


DEL(A) 

r;A®A  ■ 

T;  A  S->A  t  T;  A  S->A  t 

- cac.ext 

DUP(A) 

T;  A  ‘Kt  (t,  £) 
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Lemma  8.10  (Dolev-Yao  Emulation  of  Term  Tuple  Constructability ) 

Let  E  be  a  signature,  A  a  knowledge  context  compatible  with  E,  and  t  a  term  tuple. 

If  4::E;  A  t,  then  ■  >  [rAn]^sDy  — >*  [r^n]EffisDy. 

Proof:  Similarly  to  the  previous  result,  the  proof  of  this  lemma  proceeds  by  induction  on  the  structure  of  4.  □ 

We  now  turn  to  emulating  the  constructability  of  predicate  sequences  using  Dolev-Yao  rules.  The  transformation  is  given 
by  the  following  table. 


r ;  A  S-»a  t  r ;  A  S->a  Ihs 

-  racnet 

r ;  A  S->a  N  ( t ) ,  Ihs 

DUP(A),  TRN 

r ;  A  S-^a  t  r ;  A  S-^a  Ihs 

-  rac.mem 

TjA^a  W\A(t),lhs 

DUP(A) 

TjAS-^a  (A,  e)  TjAS-^a  Ihs 

rac  rsp 

r^As-u  L(A,e),lhs 

r;As->4  ( A,t )  Ihs  UA^  ( A,t )  UA^a  Ihs 

rac  rsp*  rac  rsp** 

TjA'Ha  L(A,t),lhs  TjAS-^a  L i(A,t),lhs 

DUP(A) 

- rac_dot 

r;As->A  • 

DEL(A) 

The  correctness  of  this  translation  is  given  by  the  following  lemma. 

Lemma  8.11  ( Dolev-Yao  Emulation  of  Predicate  Sequence  Constructability ) 

Let  E  be  a  signature,  A  a  knowledge  context  compatible  with  E,  and  Ihs  a  predicate  sequence. 

If  4  ::  E;  A  Ihs,  then  •>  [rAn]  s®sDy 

Proof:  Once  more,  this  proof  proceeds  by  induction  on  the  structure  of  A.  The  case  in  which  A  ends  in  rule  rac_dot  is 
handled  similarly  to  rule  cac  ukn  in  Lemma  [879]  Rules  rac  mem  and  rac  rsp  are  treated  similarly  to  rule  cac  cnc  in  the 
proof  of  same  result.  Finally,  rule  rac_net  follows  again  this  pattern,  but  it  should  be  prefixed  by  an  application  of  the  role 
TRN  that  appears  in  the  translation.  □ 

Finally,  we  give  the  translation  of  a  data  access  specification  derivation  for  an  entire  rule  consequent. 


(T,x  :  nonce);  (A,  x)  \\~a  rhs 

-  rac  nnc 

T;  A  II ~a  ^x  :  nonce,  rhs 

GNC 

(r,  x  :  msg);  (A,  x)  IKa  rhs 

rac  msg 

T;  A  IKa  3x  :  msg.  rhs 

GMS 

T;  A  S^a  Ihs 

rac  ps 

T;A  lhA  Ihs 

The  correctness  of  this  translation  follows. 

Lemma  8.12  ( Dolev-Yao  Emulation  of  Right-Hand  Side  Constructability ) 

Let  E  and  E'  be  signatures,  A  a  knowledge  context , compatible  with  E  rhs  a  rule’s  right-hand  side,  and  Ihs  a  predicate 
sequence  such  that  the  judgment  “( rhs )s  (Ihs)s'  ”  is  derivable. 

If  4  ::  E;  A  lb,  rhs,  then  •>  [rAn]^sDy  — >*  [rlhsn]  s,0Em„. 
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Proof:  The  proof  proceeds  by  induction  on  the  structure  of  A.  Let  £r/,„s  be  the  given  derivation  of  “(rhs) s  (Ihs)^’’.  We 

will  examine  only  the  case  in  which  it  ends  in  rule  rac_nnc. 


A  = 


Ai 

(T,  x  :  nonce);  (A,  a;)  \\~A  rhs' 


■  rac_nnc 


T;  A  \\-A  3a:  :  nonce,  rhs' 
with  rhs  =  3a:  :  nonce,  rhs' .  Recall  that  rA~l  =  rA-\  n,  GNC. 


S rhs  "  {\t\  /  Xt\rhs  )s,n:nonce  ( hlS ) 5] ' 


Si 

s 


r  A  -11  GNC,rair 

J  S®5j£)  y- 


■An,/(n)]"-lVn  nn 

v  /  J  2j® 2-idy  j n . n 


>*  \rrhs'^- 


•>  rA^./ln)!,^1  ,  I  ins 

L  ?  V  /J  (2],n:nonce)®2]£)y  L  J  x,  ®Aj dy 

•  t>  lrAnl  GNC>rAin  _ ,*  f r „ z, c ,  — 1 1  ' 

^  1  ^  Je@Ej3v  *  1  rns  Js'®EDr 


by  inversion  on  Srhs, 
by  using  role  GNC, 
by  induction  hypothesis  on  S'rhs  and  Ai, 


by  the  Chaining  Lemma  6.1  on  Sq-Si. 


Observe  that  firing  role  GNC  involves  selecting  a  constant  of  type  nonce  that  does  not  appear  in  £  ®  EJJV.  We  choose 
the  constant  n  that  appears  in  S'rhs.  Rule  rac  msg  is  treated  identically  to  rule  rac  nnc,  while  rule  rac  ps  relies  on  the 
Constructability  Lemma[8.11|for  predicate  sequences.  □ 


8.2.4  Dolev-Yao  Emulation  of  Rule  and  Roles 

We  will  now  glue  the  translations  of  data  access  specification  derivations  of  the  antecedent  and  of  the  consequent  of  a  rule 
together  and  use  them  to  translate  roles.  As  we  will  see,  most  judgments  will  not  produce  any  additional  Dolev-Yao  rules. 

We  begin  with  the  judgment  L  b4  r  which  handles  MSR  rules.  It  is  translated  according  to  the  following  (vacuous)  table 
(the  real  work  is  being  done  by  the  translation  of  the  premises). 


T;-  \\~a  Ihs  >  •  ^>  A  T;  A  \\~a  rhs 

-  uac.core 

r  lh^4  Ihs  — »■  rhs 
(r,  x  :  t )  I  Ha  r 

- uac_all 

r  I  \~a  Vx  :  r.  r 

The  correctness  of  this  strategy  will  be  established  later,  when  we  look  at  entire  protocols.  Instead,  we  show  that  the 
transformation  of  all  the  judgments  we  have  analyzed  so  far  is  invariant  with  respect  to  term  substitution. 

Lemma  8.13  (Emulation  Invariance  under  Substitution) 

Let  £  and  S'  be  signatures,  t  a  term,  r  a  type,  x  a  variable,  and  T  a  typing  context  fragment  such  that  the  judgments 
£,£'  b  t  :  t  and  b  (£,  a:  :  r,  T)  hold.  Furthermore, 

•  let  A  be  a  knowledge  context  and  T';A  lb|  X  >  Y  Z  an  data  access  specification  judgment  among 

T';  A  lb,  k  >  A'  T';  A  1^  fc»A'  T;  A  lb,  A'  T';  A  lb,  Ihs  >  f  >  A' 

T  bi  e  TjA®  f  TjA®  t  T';  A  CH|  Ihs  T';A  lb,  rhs 

r  ib,  r  r  ib,  P 

(Y  and  Z  are  defined  only  for  judgments  with  more  than  tw’o  (resp.  three)  objects  to  the  right  of  the  turnstile  symbol.) 

For  every  derivation  A  of  (£,x  :  r,T);  A  lb,  X  >  Y  Z,  there  exists  a  derivation  A[t/X\  of  (£,£',  [t/xjT);  [t/x]A  lb, 
\t/x]X  >  [t/x]Y  S>  \t/x]Z  such  that 

r-4n  = 
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let  A  and  A'  be  knowledge  contexts  and  t  a  tuple  consisting  of  either  ground  terms  or  variables. 

For  every  derivation  A  of  A  >  t  >  A',  there  exists  a  derivation  A\t/X]  of  [t/x\A  >  [t/x]t  >  [t/x] A'  such  that 

r-bT  =  ^A[t/xf 


Proof:  By  the  Term  Substitution  Lemma  6.17  we  know  that  there  is  a  derivation  A\tix\  of  the  postulated  judgments.  A  close 


inspection  of  the  proof  of  this  property  reveals  that  the  specific  derivation  Ayt/X\  it  constructs  has  the  same  structure  as  A.  i.e. 
consists  of  the  application  of  the  exact  same  rules  in  the  same  order,  although  to  different  instances  of  their  meta- variables. 

We  shall  now  observe  that  rA~ 1  is  constructed  on  the  basis  of  the  structure  of  A  and  independently  from  the  actual 
instances  of  the  meta-variables  it  accesses  (except  for  the  presence  of  correlations  that  are  preserved  in  A[t/X\).  Therefore, 
since  A  and  share  the  same  structure,  we  deduce  that  rAn  =  rA[t/x P. 

□ 


A  formal  proof  of  this  result  proceeds  by  induction  on  the  proof  of  the  Term  Substitution  Lemma  6. 17 


The  emulation  of  a  role  simply  accumulates  the  Dolev-Yao  rules  that  result  from  the  emulation  of  its  constituents. 


- oac.dot 

r  lbA  • 

(r,  L  :  f)  \\~ a  P 

oac  rsp 

r  ibA  3 L-.r.p 

r  ihA  r  r  ihA  P 

- oac_rule 

r  lhA  r,p 

Again,  the  correctness  of  this  translation  will  be  established  at  the  protocol  level.  We  have  a  result  similar  to  Lemma  8.13 
concerning  the  instantiation  of  role  stat  predicate  symbols. 


Lemma  8.14  ( Emulation  Invariance  under  Role  State  Predicate  Symbol  Substitution) 

Let  E  and  S'  be  signatures,  L;  and  L  a  role  state  predicate  constant  and  variable  respectively,  t  a  tuple  type,  T  a  typing 
context  fragment,  A  a  knowledge  context  compatible  with  E,  and  F;  A  lb A  X  >  Y  Z  an  data  access  specification 
judgment  among 

F;  A  \\-A  Ihs  >  A'  r'jAs-u  Ihs  F;  A  lbA  rhs  F  lhA  r  F  lbA  p 

(Y  and  Z  are  defined  only  in  the  first  of  these  judgments;  A  does  not  appear  in  the  last  two.)  Assume  that  b  (E,  L;  :  r,  E7) 
and  b  (E,  L  :  t ,  T). 

Then  for  every  derivation  A  of  (E,L:r,  T);A  lbA  X>Y^>Z,  there  exists  a  derivation  A^/l]  of  (E,E',r);A  lbA 
[L i/L\X  >  Y  Z  such  that 

rA^  =  F4[Ll/if 


Proof:  This  result  relies  on  the  same  proof  technique  already  sketched  for  the  Term  Substitution  Lemma  8.13 


□ 


Given  a  derivation  A  of  E  lb  R,  we  construct  r A~  by  collecting  the  active  roles  corresponding  to  the  annotation  of  each 
rule  that  appears  in  A.  We  define  rRn  as  rA~l. 


-  aac.dot 

S  lb  • 

S  lb  R  E  lb A  p 

pA  if  A  f\ 

E  lb  i?,pA 
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It  is  instructive  to  unfold  this  definition  to  the  level  of  active  roles: 


fri?n  rA~1  if  A  I,  where  A  is  a  derivation  of  £  b,  p 
|rf?n  (p)A  otherwise 


Here,  A  consists  exclusively  of  Dolev-Yao  roles  from  V nY  ■ 

Given  a  protocol  theory  V  and  a  derivation  A  of  £  b  V,  we  translate  r A~  by  collecting  the  translation  of  every  role 
occurring  in  V . 


The  following  lemma  ensures  that  the  emulation  introduced  in  the  last  three  sections  transforms  well-typed  objects  into 
well-typed  entities. 


Lemma  8.15  ( Typability  of  the  Dolev-Yao  Emulation ) 

Let  Y  be  a  signature,  V  a  protocol  theory,  S  a  state  and  R  an  active  role  set.  Let  moreover  Ydy  and  VDY  be  the  signature 
and  protocol  theory  for  the  Dolev-Yao  intruder. 

L  If  b  £,  then  b  £,  Ydy; 

2.  If  £  b  V,  then  £,£„,-  b  rV^,VOY; 

3.  If  £  b  S,  then  Y,Ydy  b  rSn; 

4.  If  £  b  R  and  A  ::  £  lb  R,  then  Y,Ydy  b  rA~1. 


Proof:  By  the  Dolev-Yao  Encoding  Validity  Lemma  8.1 
the  Weakening  Lemma  6.6  b  £,  £ 


we  know  that  b  Ydy  and  Ydy  b  VDY  have  derivations.  By 


is  therefore  derivable.  Parts  (2)  and  (3)  rely  on  the  same  lemma  and  on  a  simple 
induction  on  the  structure  of  a  derivation  for  their  premise.  Point  (4)  is  proved  similarly;  it  uses  the  fact  that  r A~  contains 
elements  from  R  (all  the  active  roles  that  are  not  owned  by  the  intruder)  and  possibly  multiple  occurrences  of  roles  from  VDY . 

□ 


We  will  need  the  following  technical  lemma  to  delete  leftover  role  state  predicate  symbols. 

Lemma  8.16  ( Deletion  of  Used  Role  State  Predicate  Symbols) 

Let  £,  £l  and  £'  be  signature  fragments  such  that  £l  consists  of  role  state  predicate  constants  declarations  only.  Let 
moreover  V  be  a  protocol  theory,  S  and  S'  two  states,  and  R,  R'  two  active  role  sets  such  that 

b  £  £bs  sb  r  v>  [S]«Sl  — >*  [S']^, 

Then  V  >  [5]  §  [S"]  §,£'■ 

Proof:  The  proof  proceeds  by  induction  on  a  derivation  8  of  “V  i>  [.S’]  |?  >Jl  — >*  [.S']  >:l  s,”.  Intuitively,  the  typing 

derivations  affirm  that  none  of  the  role  state  predicate  symbols  in  £l  appear  in  S  or  R  (they  clearly  cannot  appear  in  V). 
Consequently,  no  transition  in  8  can  make  use  of  them.  Therefore,  they  can  be  dropped.  □ 
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Our  emulation  does  not  interfere  with  actions  that  involve  non-intruder  roles.  Installing  a  role  p1  anchored  on  I  into 
the  current  active  role  set  (rule  ex_arole)  is  emulated  by  copying  as  many  instances  of  objects  from  VDY  as  specified  by  the 
encoding  of  p\  Intruder-instantiated  generic  roles  (rule  ex  grole)  are  treated  in  the  same  way,  which  means  that  our  emulation 
does  not  allow  I  to  directly  execute  a  generic  role.  Uses  of  rule  ex  all  to  instantiate  a  universal  variable  in  an  active  intruder 
rule  do  not  correspond  to  any  action:  we  have  proved  that  data  access  specification  is  preserved  under  substitution  03  and 
that  this  process  does  not  affect  the  encoding  of  an  data  access  specification  derivation.  Finally,  the  application  of  a  fully 
instantiated  intruder  rule  (ex_core)  relies  on  results  such  as  the  above  that  specify  the  behavior  of  its  constituents. 


Theorem  8.17  (Dolev- 


iuo  emulation  oj  me  . 


Let  V  be  a  protocol  theory  S  and  S'  two  states,  R  and  R'  two  active  role  sets,  E  and  E7  signatures  such  that 
E  V  V  E  \-  S  Eh  R  E  lh  7^ 

*<*>  [S']£Eo  then  (rr,PDy)>r^]^ 


h  E 

If 

where  E*  is  a  subsignature  o/E7  such  that  E7  =  E*,  E|_  and  E|_  consists  only  of  role  state  predicate  symbol  declarations. 


A  ::  E  Ih  R  A'  ::  E,  E7  Ih  R' 

*  rrc/T|r.4'n 

1  °  Je®Edv,E* 


Proof:  The  proof  of  this  theorem  proceeds  by  induction  on  the  structure  of  a  derivation  £  of  the  given  execution  judgment 
“ V  >  [5]  §  — >*  [S']  §  £'”•  We  distinguish  cases  on  the  basis  of  the  last  rule  appearing  in  £.  With  the  exception  of  sex_itO 
and  sex_itn,  we  must  consider  two  subcases  for  every  rule:  whether  the  action  applies  to  an  object  with  owner  I,  or  not. 


sex_arole,  A  f  I 


£  = 


sex_arole 


I  R,pa 


(V*,pA)>  [S]£  — ►  [S]s 
with  V  =  (V*,PA),  R'  =  R,  pA,  S'  =  S  and  E7  =  •. 


rV*n,pA 


r-p-i 

Ap  ::  E  lhA  p 
A'  ::  E  Ih  R,pA 
rAn=rA^,pA 

£'  ::  rV^,pA,VDr)>  [r^]^E, 


*  rr^/nl  r^tn.P 


I  E®Ei 


by  definition  of  the  Dolev-Yao  translation, 
by  inversion  on  rule  hac_arole  for  A-p, 
by  rule  aac  ext  on  Ap  and  A, 
by  definition  of  the  Dolev-Yao  translation, 
by  rule  sex  arolc. 


sex  arolc,  A  =  I 


Here  V  =  {V* ,  p')  and  R’  =  R,p'. 


Ap  ::  E  Ih,  p  by  inversion  on  rule  hac_arole  for  Ap, 

By  definition  of  the  Dolev-Yao  translation,  r  A/f  is  composed  of  a  finite  number  of  copies  of  intruder  roles  from  VDY  ■ 
With  this  theory  at  our  disposal,  we  can  individually  copy  them  to  the  current  active  role  set  by  means  of  rule  sex_arole. 
The  formal  proof  proceeds  by  induction  on  the  structure  of  r  A ff .  We  omit  it  for  the  sake  of  conciseness. 

Therefore, 

£’  ::  (rV* ,  pl_l,  VDY)  >  [r<S'_l]  by  several  applications  of  rule  sex_arole. 

Observe  that  rV* ,  p1  n  = 


r 

E  h  A  :  principal 

-  sex_arole 

(V*,pyA)>  [S]g  — >  [S]  £’([A/A]rfA 
with  V  =  (VfpWA),  R'  =  R,{[A/A]p)A,  S'  =  S  and  E7  =  ■. 


sex  grolc,  A  f  I 
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Ap  : 

:  E,  A  :  principal  lbA  p 

A'  • 

:  E  lbA  [A /A\p 

A!  : 

:  E  lb  S,([A/A]p)A 

r 

L 

=  ^,([A/A]p)A 

£'  : 

:  (rr*A,pWA,VDY)>  [ 

by  inversion  on  rule  hac_grole  for  A-p, 
by  the  Substitution  Lemma 


6.17 


on  Ap  and  T, 


by  rule  aac_ext  on  A'p  and  A, 
by  definition  of  the  Dolev-Yao  translation, 


rA n 


[r<S"n]  S®EDt/AIP)  by  mle  sex_grole. 


sex_grole,  A  =  I  Here  V  =  (V*,ff  A)  and  R’  =  R,  ([I /A\p)\ 


A  a  E,  A  :  principal  lbA  p 

Ap  ::  E  lb,  [I /A]p 


by  inversion  on  rule  hac_grole  for  Ap, 

on  A'  and  T, 


by  the  Substitution  Lemma 


6.17 


As  in  the  case  of  rule  sex  arolc  (with  A  =  I),  the  translation  rAf£  consists  of  a  finite  number  of  copies  of  intruder 
roles.  We  copy  them  from  VDY  to  the  active  role  set  by  means  of  rule  sex  arole.  Therefore, 

_ i*  IT  i 


£'  -  (rv*,P^,vDY)> 
£=  — 


Sn]  y,®t.dy  by  several  applications  of  rule  sex_arole. 


sex_rsp,  A  ^  I 


Vt> 


roi  R\([U/L}p)k 
L’J  (S,Li:f) 


with  R  =  R*,(3L  :  f.  p)A,  Rf  =  R*,  ([L;/L]p)A,  S' =  S  and  E7  =  L,  :  r. 


Ar*  ::  E  lb  R* 

rA~l  =  r  Ar?  ,  (3L  :  t.  p)A 

rA'A=rAR^,([U/L}p)A 


£'  ■■  (rv^,vDY)»r 


-  onl  rAR.-',([Ll/L]p)A 
J  S®Sdy  ,L i  :r 


by  inversion  on  rule  aac  ext  for  A  or  A! , 
by  definition  of  the  Dolev-Yao  translation, 
by  definition  of  the  Dolev-Yao  translation, 

by  rule  sex_rsp. 


sex_rsp,  A  =  I  Here  R  =  R* ,  (3 L  :  r.  p)1  and  R'  =  R* ,  ([L J L\p)\ 


Ar .  ::  E  lb  R* 

Al  ::  E  lb,  3L  :  r.  p 

rA-'  =  ('-AR?,rAL~') 

Ap  v.  E,  L  :  t  lb,  p 
A'p  ::  E,  L,  :  r  lb,  [h/L]p 

r  A'P  _  r  A  n  —  rjri 

vTT-p  -  J^p  - 

^A'A=rAR^AA^) 

£  ::V>r  ^]rE®C’^ 


and 

by  inversion  on  rule  aac_ext  for  A, 
by  definition  of  the  Dolev-Yao  translation, 
by  inversion  on  mle  oac_rsp  for  Ap, 
by  the  Substitution  Lemma  6.18  on  7>:  and  Ap, 


'S'-1] 


^R*  ,  J 

S©E£)v 


by  the  Invariance  Lemma  8.14  on  7>j  and  Al, 
by  definition  of  the  Dolev-Yao  translation, 

by  rule  sex_itO. 


T 

E  b  t  :  t 


sex_all,  A  I 


£  = 


I  R*  ,{([t/x]r),p)A 


all 


7>>  [S]£  [S]E 

with  R  =  R* ,((Wx  :  r.r),  p)A,  R'  =  R* ,  (([t / x\r) ,  p)A ,  S' =  S  and  E7  =  •. 

Similarly  to  the  case  of  rule  sex_rsp  (with  A  A  0.  the  Dolev-Yao  translation  does  not  directly  affect  the  applicability 
of  the  rule.  We  proceed  as  in  that  case. 
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sex_all,  A  =  I 


Here  R  =  R* ,  ((Vx  :  r.  r),  p)1  and  R'  =  R*,  (([f/x]r),  p)1. 


Ar •  ::  E  lh  f? 

::  E  lh,  p 

A/  "  E  I  hj  Vx  :  t.  r 


=  (r^«VA>  V-4vn) 

^4r  ::  E,  a;  :  r  lh,  r 


.4J,  ::  E  lh,  [t/x\r 
rA'A  =  rAr n  =  rAn 
AT  Ar-4*ArAArAA) 

£  ::  V>m^YAf  ’  ^  ->*  ’ 


and 

and 

by  inversion  on  rules  aac  ext  and  oac  rule  for  A, 

by  definition  of  the  Dolev-Yao  translation, 

by  inversion  on  rule  uac_all  for  Ay, 

by  the  Term  Substitution  Lemma|6.17|on  7s,  T  and  Ar, 

by  the  Invariance  Lemma  8.13|on  7s-  T  and  A,/, 

by  definition  of  the  Dolev-Yao  translation, 

by  rule  sexJtO. 


(rhs)-z  >  (lhs')x,v 


sex_core, 


,  A  /  I 


£  = 


sex_core 


Vt>  [S*,lhs]^Mlhs^rhs)’p)A 


[S*,lhs']«%\p)A 


with  R  =  R\  (( Ihs  ->  rhs ),  p)A,  R'  =  R* ,  (p)A,  S'  =  S*,  Ihs  and  S'  =  S*,  Z/A. 

We  proceed  again  as  in  the  case  of  rule  sex_rsp  (for  A  /  I).  It  should  be  noted  that  rlhs n  =  Ihs  since  Ihs  cannot 
contain  role  state  or  memory  predicates  whose  first  argument  (resp.  index)  is  I.  This  is  due  to  the  existence  of  A, 
which  entails  that  “E  lbA  ( Ihs  — ►  rhs)”  is  derivable.  The  formal  argument  proceeds  by  induction  on  the  structure  of  a 
derivation  for  this  judgment.  By  a  similar  argument,  rlhs'~'  =  Ihs1 . 


sex_core. 


A  =  I 


Here  R  =  R* ,  ((Ihs  — ►  rhs) ,  p)1  and  R’  =  R*,  (p)1. 


Ar  *  ” 

E  lh  R* 

Ap  :: 

E  lh,  p 

Aihs  ■■ 

E;  •  lh,  Ihs  >  ■  »  A 

Arhs  •• 

E;  A  Ihj  rhs 

II 

r 

L 

(r  Ar?  ,r  A,A  ,r  Aihs 

S Ihs  •• 

•>  - 

°lhs  ** 

■> 

Srhs  •• 

•>  TATesC,  - 

£*  :: 

•>  lrlhsAr^’^ 

S'  :: 

(rV^,VDY)>  [rs*n 

V-W) 

_j*  rrAn 


J  S®Si)y 

An] 


•A.rhs 


7/ts' 


rlhs'^ 


r-4n 

Ie®Sdy 


Y/is 


,_il 

S'®Soy 


and 

and 

and 

by  inversion  on  A, 

by  definition  of  the  Dolev-Yao  translation, 
by  the  Left-Hand  Side  Decomposability  Lemmas 

A  ms. 


8.6 


on 


by  the  Execution  Weakening  Lemma  6.4  on  £ihs. 


by  the  Right-Hand  Side  Constructability  Lemma  8.12 

on  Arhs  and  £' 


by  the  Chaining  Lemma 


6.1 


on  £'[ha  and  £rha. 


by  the  Execution  Weakening  Lemma 


6.4 


on  £*. 


sex_skp,  A  ^  I 


£  = 


v>  [s]£*,(r’p)A 


sex_skp 


[^]  E 


R*,(Pr 


with  R  =  R*,  (r,  p)A,  R'  =  R*,{p)A,  S' =  S  and  S' = 
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We  proceed  again  as  in  the  of  rule  sex_rsp  (for  A  /  I). 


sex  skp,  A  =  I 


Here  R  =  R*,  (r,  p )'  and  R'  =  R*,  (p)K 


Ar *  ::  E  lb  R*  and 

Ap  ::  E  lb,  p  and 

Ar  ::  E  lb,  r  by  inversion  on  rules  aac_ext  and  oac_rule  for  A, 

rA~1  =  r  Ar^  A Ap^ ,  r  AA  by  definition  of  the  Dolev-Yao  translation. 

Observe  that  rAA  is  composed  of  a  finite  number  of  copies  of  roles  taken  from  VDY.  In  particular,  each  of  these  roles 
consists  of  a  single  rule,  and  no  role  state  predicate  declarations  are  present.  Assume  therefore  that  rAA  is  given  by 
the  following  sequence  of  one -rule  roles  (ri,  ,  (rn,  ■)  ,  where  we  have  included  the  trailing  for  completeness. 

Intuitively,  we  emulate  the  action  of  rule  sex_skp  on  r  as  follows:  for  each  component  (rt ,  •)'  in  rAn,  we  apply  rule 

sex_skp  to  produce  the  empty  role  (-)1,  which  we  immediately  eliminate  thanks  to  rule  sex_dot.  The  formal  proof 
proceeds  by  induction  on  the  structure  of  r  AA-  We  omit  it  for  the  sake  of  conciseness. 


Therefore, 


£' 


Avn,vDY)>[rsA 


<-AR*-'rApnrA^ 

S©S£)V 


^An.-'pAp-' 


by  applications  of  rules  sex  skp  and  sex  dot,. 


c_dot,  A  A  i  £  = 


v>  [5]«'(-)A 


■  sex_dot 


R' 


[£]  s 


with  R  =  R' ,  (-)A,  S'  =  S  and  E'  =  •. 

or  =  r^,(-)A 

£'  ■■  (rrAvDY)>  - 


~lF]rz 


S0S  dy 


by  definition  of  the  Dolev-Yao  translation, 
by  rule  sex_dot. 


sex_skp,  A  =  I 


Here  R  =  R',(-)'- 


rAn=  rA'~'A(-y^  =  rA’~i 
S’  ::  AVAVdy)>  [^Te^e 


S0Sdy 


by  definition  of  the  Dolev-Yao  translation, 
by  rule  sex_itO. 


sex_itO 


£  =  ■ 


■  sex_itO 


R 


- 1  P>[S]£  — >*  [5]s 

with  R’  =  R,  S'  =  S  and  S'  =  •. 

?  -  (rrAvDY)>  - 


rA~"  _ s*  jrcpj 


rA n 

S©Sdy 


by  rule  sex_itO. 


sexJtn 


Si 

t»  [s]g  — >  [5*]«;s,  P>[5*]«* 


£1 


[S'] 


n  R' 


£  = 


V>  [5]; 


with  S'  =  E' ,  e;2. 


S'l  ■■  (rVAVDY)>  [^Te^e 


[S']  e,e',e' 


sex_itn 


*  rrg*ni  sir 


£'*  ■■  Avn,vDY)t>  [rs*n] 


S0X)£)v 


I  S0Sdy 

-  c/ni  rA'~l 

J  S0Edy,S/1,S 2 


by  induction  hypothesis  on  £\ , 
by  induction  hypothesis  on  £2, 
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Tr 

'  Z-'DY 

::h  E©Eoy 

Trs -i  : 

:S©EDy  h  rS~[ 

7r^-i  : 

:£©EDy  h  rAn 

'  £ dy 

::h  E  ©  E DY,  E^ 

/7“* 
frSA  • 

:  S  ©  T,dy  h 

,rA^  * 

:  E  ©  T,dy  h  rAR£ 

£*2  ■■ 

(rV^VDY)>  - 

->*  [rS'n][ 

£'  :: 

irv^vDr)>  rs"]^ 

rr  o/-il  rAl~' 
l  °  J  E©£ 

by  the  Typability  Lemma  8.15  on  7e, 


by  the  Typability  Lemma  8.15  on  7s, 
by  the  Typability  Lemma  8.15  on  A, 
and 
and 

by  the  Type  Preservation  Theorem 

7sDy’  7i and  7r\4n> 


by  the  Deletion  Lemma 

7r*A-,  and  £f>, 

by  the  Chaining  Lemma 


8.16 


6.15 


on 


011  7r 


rS~l ’ 


6.1 


on  £[  and  £|  ■ 


This  concludes  the  proof  of  this  theorem.  □ 

Since,  in  models  that  relies  on  black-box  cryptography,  an  attack  of  any  kind  is  ultimately  an  execution  sequence  between 
two  snapshots,  this  theorem  states  that  a  security  protocol  has  an  attack  if  and  only  if  it  has  a  Dolev-Yao  attack.  This  justifies 
the  design  of  tools  that  rely  on  the  Dolev-Yao  intruder  iflOl  |43l  l49l  [ST!  l54l  [57l  l58l.  but  it  does  not  mean  that  considering 
other  specifications  of  the  attacker  is  pointless.  Indeed,  precisely  because  of  its  generality,  a  straight  adoption  of  the  Dolev- 
Yao  intruder  often  results  in  inefficient  verification  procedures.  Overhead  can  be  greatly  relieved  by  relying  on  general 
optimizations  that  cut  the  search  space  fl6l  [42 .  50  57 1  and  on  per-protocol  specializations,  for  example  allowing  the  intruder 
to  construct  only  message  patterns  actually  used  in  the  protocol  ifSTI  1541.  Linally,  the  environment  in  which  a  particular 
protocol  is  deployed  may  be  so  constraining  that  a  weaker  attacker  model  is  sufficient  to  ensure  the  desired  security  goals. 

Our  result  extends  to  settings  that  involve  multiple  intruders  l1; . . .  Ira.  We  process  each  of  these  attackers  independently 
as  specified  above,  obtaining  n  copies  of  VDV,  each  anchored  on  a  particular  1,;.  We  then  make  use  of  the  attack-preservation 
result  in  |59l  to  reduce  them  to  a  single  attacker  I 


8.3  An  Optimized  Dolev-Yao  Intruder 


We  will  now  present  an  optimized  variant  of  the  Dolev-Yao  intruder  discussed  above.  Whenever  the  adversary  intercepts 
a  message,  we  will  have  him  decompose  it  in  its  most  elementary  bits,  store  them  in  a  dedicated  memory  predicate,  and 
construct  any  message  intended  for  transmission  from  stored  elementary  terms.  We  can  therefore  partition  the  actions  of  the 
intruder  in  three  distinct  activities:  message  decomposition,  storage  of  elementary  information,  and  message  construction. 
This  idea  was  first  proposed  in  l50l  and  analyzed  in  an  earlier  version  of  MSR  in  l27l. 

In  order  to  formalize  this  idea  in  MSR ,  it  is  convenient  to  slightly  revise  the  subsorting  relation  presented  in  Section  |2.2| 
Namely,  we  introduce  the  sort  atm  which  stands  for  atomic  messages.  We  make  all  types  classifying  elementary  information 
a  subsort  of  atm: 

- ss,_pr  - ss'-nnc 

principal  ::  atm  nonce  ::  atm 


shK  A  B  ::  atm 

while  atm  is  made  a  subsort  of  msg: 


shK 


pubK  A  ::  atm 


■  ss7_pbK 


atm  ::  msg 


ss'.atm 


We  leave  it  as  an  exercise  to  the  reader  to  update  the  typing  rules  presented  in  Section  2.3  and  the  proof  of  the  various  results 
in  this  report. 

We  replace  the  single  memory  predicate  M|(_)  used  in  Section  8.1  with  three  predicates,  D|(_),  A|(_)  and  Q(_).  The  first 
is  intended  to  contain  messages  while  they  are  decomposed  into  their  elementary  constituents.  The  second  holds  the  atomic 
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terms  learned  in  this  way.  The  third  is  used  in  the  message  construction  phase.  Our  signature  shall  therefore  contain  the 
following  four  declarations: 

I  :  principal  ,  D_  :  principal  x  msg  ,  A_  :  principal  x  atm  and  C_  :  principal  x  msg 


The  interception  and  transmission  rules  are  updated  as  follows: 

(Vi  :  msg.  N(f)  — )•  D|(f))' 


(Vi  :  msg.  Q  (i) 


N (i)) ' 


Observe  that  an  intercepted  message  is  placed  in  the  decomposition  memory  predicate  since  it  must  be  disassembled  before 
its  elementary  constituents  can  be  used.  Dually,  only  constructed  messages  can  be  transmitted  over  the  public  network.  This 
is  enforced  by  having  a  construction  predicate  in  the  antecedent  of  the  rule  on  the  right. 


The  rules  that  dealt  with  composite  message  in  Section  8.1  are  adapted  by  replacing  the  generic  M_  predicate  with  the 
appropriate  refinement.  When  decomposing  a  message,  its  components  may  need  further  disassembling.  Dually,  messages 
intended  for  transmission  are  built  by  putting  together  constructable  pieces.  Keys  constitute  an  exception  to  this  rule:  they 
are  clearly  atomic  and  therefore  can  be  accessed  from  the  A  predicate  where  such  information  is  stored.  We  also  need  to 
copy  them  to  the  consequent  of  rules  so  that  the  intruder  can  use  them  again  for  other  encryptions  (as  we  will  see  shortly,  this 
optimized  scheme  does  without  an  explicit  duplication  rule). 


^Vfi,f2:msg.  D|(f!f2) 


D,(tiA 

D,  (t2y 


^Vfi, f2  :  msg. 


C,(fi) 

C,(t2) 


C,(fi  t2 ) 


i 


(VA,  B  :  principal. 
V/c  :  shK  A  B. 

Vf  :  msg. 


Di(Wfc) 

A,(fc) 


— ► 


D,  (t)\ 
A,  (k) ) 


VA,  B  :  principal. 
V/c  :  shK  A  B. 

Vf  :  msg. 


c.(t) 

A|(fc) 


C,(Wfc)V 

A  ,(k)  ) 


/VA  :  principal. 

V/c:  pubK  A.  D|({{f][fc) 

Vk'  :  privK  k.  A|(/c') 

\Vf  :  msg. 


D,(f) 

Ai(fc') 


VA  :  principal. 
V/c  :  pubK  A. 
Vf  :  msg. 


Ci  CO 

A|(/c) 


c,({W}fe)V 

A,(fc)  J 


It  should  be  observed  that  the  above  rules  do  not  apply  to  situations  where  the  intruder  does  not  know  the  decryption  key  of 
a  ciphered  message.  We  will  treat  this  case  shortly. 

Once  a  captured  message  has  been  reduced  to  its  atomic  constituents,  they  are  memorized  in  individual  A  predicates  by 
the  following  rule: 

(Va  :  atm.  D|(a)  — >  A| (a,)) ' 

The  atomicity  of  the  decomposable  message  in  this  rule  is  enforced  by  assigning  type  atm  to  the  variable  a. 

As  observed  earlier,  not  all  terms  can  be  decomposed  into  to  their  atomic  constituents.  In  particular  encrypted  message 
cannot  be  exposed  unless  the  intruder  has  access  to  the  proper  decryption  key.  The  following  rule  is  intended  to  deal  with  this 
situation.  Here,  a  message  f  being  disassembled  is  promoted  as  a  constructable  term.  Observe  that  a  copy  of  f  is  is  kept  in  the 
decomposition  queue  in  the  eventuality  that  later  captured  information  may  allow  breaking  f  into  more  elementary  pieces. 


^Vf  :  msg.  D|(f) 


D,(f)\ 
C  i{t)J 


It  should  be  observed  that  this  rule  provides  a  loophole  in  the  scheme  discussed  in  this  section  since  it  allows  any  message 
to  transit  from  the  decomposition  pool  to  the  construction  queue  without  accessing  its  atomic  components.  To  avoid  this, 
it  would  be  tempting  to  specialize  this  rule  to  the  situations  where  f  is  indeed  an  encrypted  message.  This  would  however 
violate  the  data  access  specification  policy. 

The  next  rule  makes  an  atomic  component  available  as  a  constructable  message.  Copying  is  required  since  this  object 
could  be  needed  again  later. 

Ai 

Va  :  atm.  Ada)  — ►  ^ 
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We  conclude  with  the  rules  that  allow  accessing  public  information  and  create  fresh  data.  The  changes  with  respect  to 
the  rules  presented  in  the  previous  section  is  limited  to  replacing  the  memory  predicate  M_  with  A_,  since  the  objects  under 
consideration  are  atomic. 

(VA  :  principal.  •  — *  A|(A))' 


A/A  :  principal. 
\\/k  :  shK  I  A. 


A/A  :  principal. 
\\/k  :  shK  Al. 


i 


A/A  :  principal. 
\yk  :  pubK  A. 


Vfc  :  pubK  I. 
Vfc'  :  privK  k. 


i 


— >  3 n  :  nonce. 


A|(n))' 


3m  :  msg. 


A|(m))' 


It  should  be  noted  that  we  have  structured  the  above  rules  in  such  a  way  that  no  explicit  copying  rule  is  ever  needed: 
whenever  atomic  or  decomposable  information  is  accessed  for  constructing  an  outgoing  message,  we  always  leave  a  copy  for 
future  use.  On  a  similar  note,  we  omit  the  deletion  rule  of  Section  8.1  this  version  of  the  Dolev-Yao  intruder  only  accumulate 
information,  never  eliminates  it. 


Proving  the  correctness  of  this  optimized  intruder  model  with  respect  to  the  role  set  presented  in  Section [8T| is  a  rather 
simple  task:  indeed,  mapping  the  specialized  predicates  D|  (_),  A|  (_)  and  Q  (_)  back  to  M|  (_)  yields  a  set  of  rules  that  is  almost 
identical  to  our  original  role  set  for  the  Dolev-Yao  intruder.  The  minor  discrepancies  brought  about  by  this  translation  are 
corrected  by  uses  of  the  structural  rule  of  deletion,  and  the  elimination  of  one  redundantly  produced  rule,  whose  antecedent 
and  consequent  are  identical. 


The  proof  of  the  corresponding  completeness  result,  which  shows  that  our  optimized  model  is  powerful  enough  to  simulate 


the  original  Dolev-Yao  intruder,  is  a  direct  consequence  of  the  Most  Powerful  Attacker  Theorem  8.17 


9  Examples 


In  this  section,  we  will  demonstrate  the  expressive  power  of  MSR  by  formalizing  a  number  of  examples.  We  start  in  Section  9. 1 


with  what  is  probably  the  most  popular  case-study  in  the  security  protocol  analysis  community:  the  Needham-Schroeder 
public-key  authentication  protocol  l52l.  Our  second  example,  in  Section  9.2  studies  a  slight  simplification  of  the  Neuman- 
Stubblebine  repeated  authentication  protocol  (53),  which  is  particularly  interesting  since  it  consists  of  two  phases,  the  second 


of  which  can  be  repeated  arbitrarily  many  times.  Our  final  and  largest  example,  in  Section  [93]  formalizes  the  OFT  key 
management  algorithms  (6).  a  proposed  standard  for  the  hierarchical  management  of  keys  in  large  multicast  groups. 


In  all  our  examples,  we  will  rely  on  the  visual  layout  for  rules  and  roles  that  we  already  used  in  Section  [8]  In  particular, 
recall  that  we  mark  types  that  can  be  reconstructed  from  the  other  information  present  in  a  rule  by  denoting  them  in  a  shaded 
font. 


9.1  The  Needham-Schroeder  Public-Key  Authentication  Protocol 


As  our  first  example  using  MSR  as  a  specification  language,  we  will  formalize  the  infamous  Needham-Schroeder  public-key 
authentication  protocol  (52) .  We  familiarize  the  reader  with  MSR  by  first  considering  the  two-party  nucleus  of  this  protocol 
in  Section  9.1.1  Then,  in  Section  9.1.2  we  tackle  a  variant  of  the  full  protocol,  which  relies  on  a  server  to  generate  session 
keys. 


9.1.1  Simplified  Protocol 

The  server-less  variant  of  the  Needham-Schroeder  public -key  protocol  (52)  is  a  two-party  crypto-protocol  aimed  at  authenti¬ 
cating  the  initiator  A  to  the  responder  B  (but  not  necessarily  vice  versa).  It  is  expressed  as  the  following  expected  run  in  the 


77 


9  EXAMPLES 


“usual  notation”  (where  we  have  used  our  syntax  for  messages): 

1.  A  — >•  B:  iriA  A^kB 

2.  B  A:  inA  nB}kA 

3.  A  — »  B: 

In  the  first  line,  the  initiator  A  encrypts  a  message  consisting  of  a  nonce  ha  and  her  own  identity  with  the  public  key  k B 
of  the  responder  B,  and  sends  it  (ideally  to  B).  The  second  line  describes  the  action  that  B  undertakes  upon  receiving  and 
interpreting  this  message:  he  creates  a  nonce  nB,  combines  it  with  A’s  nonce  riA,  encrypts  the  outcome  with  A’s  public  key 
kA ,  and  sends  the  resulting  message  out.  Upon  receiving  this  message  in  the  third  line,  A  accesses  nB  and  sends  it  back 
encrypted  with  kB.  The  run  is  completed  when  B  receives  this  message. 

MSR  and  most  modern  security  protocol  specification  languages  describe  the  sequence  of  actions  that  each  principal 
involved  in  a  protocol  executes.  We  called  such  sequences  roles.  Strand  spaces  l47ll  are  a  simple  and  intuitive  notation  that 
emphasize  this  notion.  The  following  strand  representation  of  this  protocol  is  given  by  the  following  picture: 

Initiator  Responder 

{{ nAA}kB  — >  — >  in A  A 


in A  nB}kA 


in  a  nB}kA 


inBJkB 


inBjkB 


Here  incoming  and  outgoing  single  arrows  respectively  denote  the  reception  and  transmission  of  a  message.  The  double 
arrows  assign  a  temporal  ordering  on  these  actions. 

We  will  now  express  each  role  in  turn  in  the  syntax  of  MSR.  The  initiator’s  actions  are  represented  by  the  following  role: 


/  3 L  :  principal  x  principal*-5'  x  pubK  73  x  nonce. 


MB  :  principal. 
MkB  :  pubK  B. 


3ha :  nonce. 


N({W  A}kB) 

L(A,  B,  kB,  nA) 


V... 

MkA  ■  pubK  A.  N({{nA  nB}kA) 
Mk'A  :privKfcyi.  L(A1B,kB,nA) 
\MnA,nB  :  nonce. 


N({{nBSfcs) 


Clearly,  since  any  principal  can  engage  in  this  protocol  as  an  initiator  (or  a  responder),  our  encoding  should  be  structured  as 
a  generic  role.  Let  A  be  its  owner.  The  first  rule  formalizes  of  the  first  line  of  the  “usual  notation”  description  of  this  protocol 
from  A’s  point  of  view.  It  has  an  empty  antecedent  since  initiation  is  unconditional  in  this  protocol.  Its  right-hand  side  uses 
an  existential  quantifier  to  mark  the  nonce  ua  as  fresh.  The  consequent  contains  the  transmitted  message  and  the  role  state 
predicate  L(A,  B,  kB.  nA).  necessary  to  enable  the  second  rule  of  this  protocol:  it  corresponds  to  the  topmost  double  arrow 
in  the  strand  specification  on  the  left.  The  arguments  of  this  predicate  record  all  the  variables  used  in  this  rule. 

The  second  rule  encodes  the  last  two  lines  of  the  “usual  notation”  description.  It  is  applicable  only  if  the  initiator  has 
executed  the  first  rule  (enforced  by  the  presence  of  the  role  state  predicate)  and  she  receives  a  message  of  the  appropriate 
form.  Its  consequent  sends  the  last  message  of  the  protocol.  The  presence  of  both  a  message  receptions  and  transmission  in 
the  same  rule  corresponds  to  the  second  double  arrow  in  the  strand  specification  of  the  initiator  of  this  role. 

Our  notation  provides  a  specific  type  for  each  variable  appearing  in  these  rules.  The  equivalent  “usual  notation”  specifi¬ 
cation  relies  instead  on  natural  language  and  conventions  to  convey  this  same  information,  with  clear  potential  for  ambiguity. 
Observe  that  most  declarations  are  grayed  out,  meaning  that  they  can  be  reconstructed  automatically:  this  simplifies  the  task 
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of  the  author  of  the  specification  by  enabling  him  or  her  to  concentrate  on  the  message  flow  rather  than  on  typing  details,  and 
of  course  it  limits  the  size  of  the  specification. 

The  rationale  behind  the  constructable  types  in  this  rule  are  as  follows.  The  universal  declarations  for  B,  kB,  and  nA  and 
the  type  of  the  existential  declaration  for  nA  in  the  first  rule  can  be  deduced  from  the  declaration  of  the  role  state  predicate  L. 
The  declarations  for  kA  and  k'A  can  be  omitted  since  the  data  access  specification  policy  requires  that  kA  be  the  public  key  of 
A,  and  k'A  be  the  corresponding  private  key.  The  only  universal  declaration  that  cannot  be  reconstructed  is  “Vn/j  :  nonce”: 
nB  is  clearly  a  universally  quantified  variable  in  this  rule,  but  there  is  no  hint  that  it  should  be  a  nonce.  Let  us  now  examine 
the  declaration  for  L:  the  first  argument  is  always  the  rule  owner,  which  is  a  principal.  The  third  argument  must  be  the  public 
key  of  some  principal  B  because  of  the  way  A: B  is  used.  Therefore,  we  only  need  to  indicate  that  B  is  bound  in  the  second 
argument  of  L. 

The  responder  is  encoded  as  the  generic  role  below,  whose  owner  we  have  mnemonically  called  B.  The  first  rule  of  this 
role  collapses  the  two  topmost  lines  of  the  “usual  notation”  specification  of  this  protocol  fragment  from  the  receiver’s  point 
of  view.  The  second  rule  captures  the  reception  and  successful  interpretation  of  the  last  message  in  the  protocol  by  B:  this 
step  is  often  overlooked.  This  rule  has  no  consequent. 


/  3L  :  principal^ 

\/kB  :  pubK  B. 
Vk'B  :  privK  kB. 

x  principal^  x  pubK  B(kB) 

x  privK  kB 

VA  :  principal. 
\/nA  :  nonce. 

WkA  :  pubK  A 

N(-8>a  A}kB) 

-A  3nB: 

V... 

\Vn_B  :  nonce. 

L{B ,  kB,k'B,  A,  nA,  kA,  nB) 

— y 

VB 


nonce. 


N  (lnAnB}kA) 
L(B,kBlk'B,A,nA,kA,nB) 


Again,  observe  that  most  typing  information  has  been  grayed  out  since  it  can  be  reconstructed  from  the  way  variables  are 
used  and  the  few  types  left. 


9.1.2  Full  Protocol 


We  will  now  specify  a  variant  of  the  full  version  of  the  Needham-Schroeder  public-key  authentication  protocol  l52l.  which 
relies  on  a  server  S  to  generate  the  keys  kA  and  kB  used  in  the  fragment  discussed  in  the  previous  section.  This  protocol  is 
written  as  follows  in  the  “usual  notation”: 


1. 

A 

-a 

s 

AB 

2. 

S 

— ► 

A 

{kB  B}kAS 

3. 

A 

-a 

B 

In A  A}kB 

4. 

B 

— ► 

S 

BA 

5. 

S 

— ► 

B 

{kA  A} fcBS 

6. 

B 

-A 

A 

inA  nB}kA 

7. 

A 

-A 

B 

lnB}kB 

The  simplified  version  discussed  in  Section  9.1.1  corresponds  to  lines  (3),  (6)  and  (7)  of  this  protocol.  In  line  (1),  A  asks 
the  server  for  a  key  to  communicate  with  B,  which  is  obtained  in  line  (2).  The  responder  issues  and  is  granted  a  similar 
request  in  lines  (4)  and  (5),  respectively.  This  protocol  differs  from  the  original  published  in  ll52l  in  that  we  used  shared-key 
encryption  rather  than  digital  signatures  as  the  format  of  the  server’s  responses.  This  small  deviation  allows  us  to  treat  this 
example  while  remaining  within  the  bounds  of  the  syntax  presented  in  this  report.  A  simple  extension  of  our  notion  of  terms 
would  allow  expressing  the  original  form  of  this  protocol. 

The  actions  of  the  initiator  are  expressed  in  MSR  by  the  following  generic  role,  which  consists  of  three  rules  that  have  to 
fire  in  sequence,  and  consequently  mentions  two  role  state  predicate  declarations.  The  first  rule  corresponds  to  line  (1)  in  the 
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“usual  notation”,  the  second  to  lines  (2)  and  (3),  and  the  third  to  lines  (6)  and  (7). 


/  3L  :  principal  x  principal. 

3 V  :  principal*"4'  x  principal*5'  x  shK  A  S  x  pubK  B  x  nonce. 


MB  :  principal. 


N(A  B) 
L(A,B) 


\ 


VA 


V... 

MkAS  :  shK  A  S. 
MkB  '■  pubK  B 


N({fcs  B}kA s) 
L(A,  B) 


3nA\  nonce. 


N(I>U  AJkB) 
L'(A,B,kAS,kB,nA) 


V... 

\/kA  :  pubK  A.  N({{nA  nB}kA ) 

\/k'A  :  privK  kA.  L'{A ,  B,  kA s,  kB,  nA) 

\MnA,nB  :  nonce. 


N(lnBjkB) 


Observe  again  that  most  declarations  and  types  can  be  reconstructed.  Notice  in  particular  that,  since  in  the  second  rule  the 
arguments  of  L  form  a  prefix  of  the  arguments  of  B ,  the  entire  declaration  for  L  can  be  synthesized  from  the  type  of  11 . 

The  responder’s  actions  are  expressed  in  the  following  generic  role.  The  first  rule  corresponds  to  lines  (3)  and  (4)  in 
the  “usual  notation”,  the  second  to  lines  (5)  and  (6),  and  the  third  to  line  (7).  Observe  again  that  most  declarations  can  be 
automatically  reconstructed. 


/  3 L  :  principal*5'  x  principal  x  pubKf?*fes'  x  privK  kB  x  nonce. 

3 L'  :  principal*5'  x  principal*"4'  x  pubK  f?*fcfl'  x  privK  kB  x  nonce  x  shK  B  S  x  pubK  A  x  nonce. 


MkB  :  pubK  B. 
Mk'B  :  privK  kB. 
VA  :  principal. 
MnA  :  nonce. 


N({W  AJkB) 


N  {B  A) 

L(B,kB,k'BlA,nA) 


\ 


VB 


V... 

Vfcgs  :  shK  B  S. 
MkA  :  pubK  A 


N({*U  A}fcBS) 

L(B,kB,k'B,A,nA) 


V... 

\/k'A  :  privK  kA. 
\Vn B  :  nonce. 


N({{ns}}feB) 

L'{B,  kB,  k'BlA ,  nA ,  kB s,  kA,  nB) 


3 nB:  nonce. 


N({W  nBJkA ) 

L,(B,kB,k'B,A,nA,kBS,kA,nB) 


The  last  role  in  this  protocol  encompasses  the  actions  of  the  server.  Assuming  that  there  is  a  single  server,  S,  they  can 
conveniently  be  expressed  by  the  following  anchored  role,  which  consists  of  a  single  rule.  The  “usual  notation”  specification 
of  this  protocol  makes  use  of  this  role  twice:  in  lines  (1)  and  (2)  to  create  f?’s  keys  for  A,  and  then  in  lines  (4)  and  (5)  for 
the  dual  operation. 

VA,  B  :  principal. 

Vfcyts  :  shK  A  S.  N(A  B)  -a  N({kB  B}kAS) 

\/kB  :  pubK  B. 

Upon  receiving  a  message  of  the  form  IM(A  B),  the  server  constructs  a  public/private  key  pair  for  principal  B  and  notifies  A 
by  sending  the  message  N ( { A: B  B}kAS).  It  should  be  observed  how  key  generation  is  specified  as  existential  quantification. 
The  use  of  dependent  types  makes  this  process  particularly  elegant. 

Notice  that  very  little  information  can  be  reconstructed  in  this  role. 


9.2  The  Neuman-Stubblebine  Repeated  Authentication  Protocol 

In  this  section,  we  provide  an  MSR  of  a  fragment  of  the  Neuman-Stubblebine  repeated  authentication  protocol  f53l.  Similarly 
to  Kerberos,  this  protocol  consists  of  two  phases.  In  a  first  phases,  a  principal  A  negotiates  a  “ticket”  with  a  server  in  order 
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to  use  services  provided  by  another  principal  B.  In  the  second  phases,  A  can  reuse  the  ticket  over  and  over  to  request  this 
same  service  from  B.  The  original  protocol  includes  timestamps  that  we  ignore  in  this  specification.  These  entities  require 


extensions  to  MSR  that  go  beyond  the  scope  of  this  report.  The  two  phases  of  this  protocol  are  examined  in  Sections  9.2.1 
and  |9.2.2|respectively. 


9.2.1  Initialization  Subprotocol 

The  Neuman-Stubblebine  protocol  1531  is  intended  to  enable  a  principal  A  to  repeatedly  authenticate  herself  to  another 
principal  B.  Typically,  B  provides  a  service  that  A  is  interested  in  using  over  and  over.  Each  time  A  intends  to  use  this 
service,  she  authenticates  herself  to  B  by  presenting  a  ticket  he  is  expected  to  honor. 

The  initialization  phase  of  this  protocol  involves  an  interaction  with  a  server  S  to  obtain  the  ticket,  as  well  as  its  first  use 
to  request  the  service  provided  by  B.  We  have  the  following  expected  trace  in  the  usual  notation: 


1.  A  — ►  B:  A  nA 

2.  B ->  S:  B  {AnATB}kB5nB 

3.  S  -»  A:  {B  nA  kAB  TB}kA s  {A  kAB  TB}kB%  nB 

4.  A  — ►  B:  {A  kAB  TBjkgs  {nB}kAB 


In  the  first  line,  A  manifests  her  intention  to  use  B’s  service  by  sending  him  her  identity  and  a  nonce  nA.  In  the  second  line, 
B  forwards  this  information  to  the  server  S  together  with  his  identity,  a  nonce  of  his  own  nB,  and  a  time  stamp  TB.  In  the 
third  line,  the  server  constructs  the  ticket  {AkAB  TB}kgs  by  combining  A’s  name,  a  freshly  generated  key  for  communication 
between  A  and  B,  and  /i’s  time  stamp.  It  is  encrypted  with  the  key  kB$  that  B  shares  with  S  so  that  A  cannot  modify  it.  The 
server  also  informs  A  of  the  extremes  of  the  ticket  in  the  message  {B  nA  kAB  TB}kA s  and  forwards  her  B’s  nonce.  In  the 
last  line,  A  identifies  herself  to  B  by  sending  him  the  ticket  and  his  nonce  nB  encrypted  with  the  newly  created  kAB. 

This  initialization  subprotocol  is  encoded  in  MSR  by  means  of  three  roles,  one  for  A,  one  for  B,  and  one  for  S.  We  start 
by  giving  a  specification  of  A’s  actions,  reported  in  the  following  role: 


/  3L  :  principal  x  nonce. 


VB:  principal. 
\/nA,nB  :  nonce. 
\/kAB  :  shK  A  B. 
\/kA s  :  shK  AS. 
\WX  :  msg. 


N {{B  nA  kAB }kA5  X  nB) 
L(A,  nA) 


3nA:  nonce. 


N(A  nA) 
L(A,  nA) 


\ 


VA 


N(X  { nB}kAB ) 
Ma(-B,  X,  kAB) 


The  first  rule  is  a  straightforward  encoding  of  line  (1)  of  the  “usual  notation”  description  of  this  subprotocol.  The  more 
interesting  second  rule  corresponds  to  lines  (3)  and  (4).  Observe  that  A  is  not  entitled  to  observe  the  inner  structure  of  the 
ticket.  We  express  this  fact  by  placing  the  variable  X  in  the  second  component  of  the  received  message.  Expanding  this 
object  as  {A  kAB  TB}kg5  to  expose  its  structure  would  violate  the  data  access  specification  policy.  In  the  consequent  of  this 
same  rule,  A  sends  the  message  on  line  (4)  of  the  informal  presentation  to  B.  She  also  needs  to  memorize  some  information 
to  be  able  to  reuse  the  ticket  in  the  future,  namely  the  ticket  itself,  the  associated  key  kAB,  and  Iks  identity.  This  is  achieved 
by  means  of  the  memory  predicate  M_.  The  type  of  this  predicate  is  principal'  l)  x  principal^  x  msg  x  shK  A  B. 

The  responder’s  actions  in  this  subprotocol  are  specified  by  the  following  role.  Its  two  rules  correspond  to  lines  (1)  and 
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(2),  and  line  (4)  of  the  “usual  notation”  specification  above. 


/  3L  :  principal*-'8-*  x  principal  x  nonce  x  shK  B  S  x  nonce  x  nonce. 


\ 


MB 


MA  :  principal. 
Mua  :  nonce. 

VfcBS  :  shKSS. 
V. . . 

WkAB  '■  shK  A  B 
\\/tib,Tb  :  nonce. 


N(A  ha) 


N({AkAB}kBS  {nB}kAB) 
L(B,  A,  ha,  kB s,  nB,  TB) 


3nB,TB :  nonce. 


N (B  {A  tia  TB}kBS  ns) 
L(B,  A,  nA,  kBs,nB,TB) 


) 


Observe  that  we  have  treated  the  timestamp  Tb  as  if  it  were  a  nonce. 

The  responder  B  does  not  need  to  memorize  any  data  to  provide  further  instances  of  the  service  needed  by  A.  Indeed,  the 
ticket  A  holds  contain  all  the  necessary  information  to  re-authenticate  her  to  B. 

Finally,  we  have  a  single  rule  that  formalizes  the  actions  of  the  server.  Upon  receiving  a  request  from  B,  the  server 
generates  the  shared  key  kAB,  constructs  the  ticket  and  the  notification  message  for  A,  and  transmits  this  information. 


AM,  B  :  principal. 

\/kAs  :  shK  AS. 
MkBS  :  shK  B  S. 


N(B  {A  nA  TB}kBS  nB) 


\MnA  ,Hb,Tb  :  nonce. 


3kAB  ■  shK  A  B.  N({B  riA  kAB  TB}kAS  {A  Tn}kns  nB) 


9.2.2  Repeated  Authentication  Subprotocol 


The  second  phase  of  the  Neuman-Stubblebine  protocol  allows  the  initiator  A  to  repeatedly  use  the  ticket  she  has  acquired 
in  the  first  phase  to  access  the  service  provided  by  B.  It  is  expressed  in  the  “usual  notation”  by  the  following  three-step 
subprotocol: 

1.  A  — >•  B:  n'A  {A  kAB  7b}/sbs 

2.  B  -»  A:  n'B  {n'A}kAB 

3.  A  — >  B:  {n'B}kAB 

In  the  first  line,  A  generates  a  nonce  n'A  and  sends  it  to  B  together  with  the  ticket  {A  kAB  Ts}kBS-  Upon  receiving  this 
message,  B  creates  a  nonce  of  his  own  n'B  and  transmits  it  to  A  in  line  (2)  together  with  the  encryption  of  n'A  with  the  key 
kAB  embedded  in  the  ticket.  In  the  last  line,  A  sends  B's  nonce  back  after  encrypting  it  with  their  shared  key  kAB- 

This  subprotocol  is  formalized  in  MSR  by  means  of  the  two  roles  below.  The  initiator’s  actions  are  expressed  by  the 
following  generic  role.  In  the  first  rule,  corresponding  to  line  (1)  of  the  informal  specification,  A  accesses  the  ticket  she 
has  stored  in  the  memory  predicate  M_  during  the  initialization  phase  of  this  protocol.  The  second  rule  corresponds  to  the 
remaining  lines  of  the  “usual  notation”  specification. 


/  3L  :  principal*"4-*  x  principal*8-*  x  msg  x  shK  A  B  x  nonce. 


\ 


V.4 


MB  :  principal. 

MX  :  msg.  MA(B,X,  kAB) 

MkAB  ■  shK  A  B. 


N  (WAX) 

3n'A:  nonce.  M A(B,X,kAB) 

L(A,  B ,  X,  kAB i  nA ) 


V...  N{n'B{n'A}kAB) 

\Mn'A,n'B  :  nonce.  L(A,B,X,kAB,n'A ) 


N(Ks}fe^B) 


The  actions  of  the  service  provider  B  are  given  by  the  following  generic  role.  Its  first  rule  captures  lines  (1)  and  (2)  of 
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the  informal  specification,  while  the  second  rule  formalizes  the  remaining  line. 

(  3 L  :  principal^  x  principal^"4'  x  nonce  x  shK  B  S  x  shK  A  B  x  nonce  x  nonce. 

\/n'A,TB  :  nonce. 


\/kB s  :  shK  B  S. 
\/A  :  principal. 
\/kAB  ■  shK  A  B. 


N(nA  {A  kAB  TB}kB s) 


— )•  3n^:  nonce. 


N (n'B  WA} kAB) 

L{B,  A,  n'A,  kB$,  kAB ,  n'B , 


\ 


Tb) 


\/b 


V...  N({n,s}fcAB) 

\VnB  :  nonce.  L(B,A,n'A,kBs,kAB,n'B,TB) 


This  concludes  our  MSR  specification  of  the  Neuman-Stubblebine  repeated  authentication  protocol.  The  two  phases 
that  constitute  it  have  been  modeled  by  providing  two  sets  of  roles.  The  connection  between  them  is  given  by  the  memory 
predicate  M_  used  by  the  client  A.  It  should  be  noted  that  this  protocol  lies  outside  of  the  scope  of  the  previous  version  of 
MSR  112711301.  which  did  not  provide  any  means  to  share  data  across  different  roles. 


9.3  Group  Key  Management 


Our  last  and  most  complex  example  will  involve  using  MSR  to  formalize  aspects  of  the  OFT  group  key  management  pro¬ 
tocol  0.  This  case  study  will  demonstrate  working  with  complex  data  structures  such  as  trees  and  lists,  realizing  primitive 
recursion  in  MSR,  and  defining  non-standard  cryptographic  operators. 


We  describe  OFT  in  Section  9.3.1  define  the  syntax  we  will  use  for  it  as  well  as  its  typing  rules  in  Section  9.3.2  and 
explain  how  we  represent  trees  and  related  data  structures  in  an  MSR  state  in  Section  9.3.3  We  will  formalize  two  subprotocols 


of  OFT:  the  joining  protocol  in  Section|9.3.4|and  the  eviction  protocol  in  Section|9.3.5 


9.3.1  Problem  Description 

The  OFT  protocol  suite  0  was  designed  for  establishing  a  common  key  shared  among  all  the  members  of  a  large  group  of 
principals,  and  maintaining  it  as  members  join  and  leave.  Intended  applications  include  pay  TV,  secure  teleconferencing,  and 
military  command  and  control.  These  applications  have  several  characteristics  in  common:  they  are  real-time,  they  involve 
potentially  large  groups,  and  membership  is  highly  dynamic  as  members  join  and  leave  the  group  frequently.  Therefore,  the 
group  key  may  change  several  times  per  second,  which  requires  providing  members  with  the  most  current  key  frequently. 
Recomputing  and  redistributing  the  group  key  must  be  done  efficiently,  even  for  very  large  groups,  or  the  key  management 
overhead  may  be  a  bottleneck  for  applications. 

OFT  relies  on  two  devices  to  achieve  high  efficiency.  First  it  logically  arranges  the  members  of  a  group  and  the  needed 
auxiliary  keys  in  a  tree,  which  allows  it  to  carry  out  key  updates  in  logarithmic  time  in  the  size  of  the  group.  Second,  it  relies 
on  multicast  to  send  key  updates  to  all  members  of  the  group  with  a  single  message.  Group  members  maintain  some  state, 
which  is  also  logarithmic  in  the  size  of  the  group. 

Each  group  is  managed  by  a  group  manager,  which  maintains  a  one-way  function  tree  for  the  group  (hence  the  name 
OFT).  This  is  a  binary  tree  with  each  leaf  associated  with  a  group  member.  Each  node  n,  whether  a  leaf  or  an  inner  node, 
has  an  unblinded  key  kn.  In  the  case  of  leafs,  this  key  is  communicated  directly  by  the  group  manager  to  the  corresponding 
member  using  a  shared  key.  In  the  case  of  an  inner  node  n,  the  key  kn  is  computed  on  the  basis  of  the  keys  kieft  and  kright  of 
its  two  children  using  the  mixing  function  f  and  the  one-way  function  g  as  follows: 

k  =  f(g(kieft),g{kmght)) 

The  group  key  is  the  unblinded  key  associated  with  the  root  of  the  tree.  While  the  group  manager  has  a  complete  view  of 
the  tree  and  of  all  the  keys  in  it,  each  member  A  knows  only  the  unblinded  key  kA  of  her  own  leaf  node,  and  the  blinded 
key  k's  =  g  ( ks )  of  the  sibling  of  every  node  ns  on  a  path  from  her  leaf  node  to  the  root  of  the  tree.  This  allows  A  to 
recursively  compute  the  unblinded  key  of  every  node  from  ua  to  the  root.  Indeed,  given  the  unblinded  key  kf\  of  her  own 
leaf  node  and  the  blinded  key  k's  of  her  sibling,  she  can  compute  the  unblinded  key  of  her  parent  node  as  kp  =  f(g(7.;,4 ),  k's). 
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Similarly,  for  any  node  n  on  this  path  for  which  she  has  computed  the  unblinded  key  kn,  she  can  compute  the  unblinded  key 
kp  =  f(g(fcn),  k's )  of  its  parent  knowing  the  blinded  key  k's  of  its  sibling.  In  particular,  this  procedure  gives  A  a  way  to  learn 
the  group  key.  Note  however  that  she  has  no  way  of  learning  the  keys  of  any  other  node  in  the  tree. 

In  this  section,  we  will  assume  that  there  is  a  single  group,  although  OFT  is  more  general,  and  write  GM  for  its  group 
manager.  We  will  focus  on  the  main  activities  of  GM:  processing  joining  requests  and  evicting  members.  Both  involve 
computing  a  new  group  key.  This  will  be  done  by  giving  one  or  more  members  a  new  unblinded  key,  which  will  trigger 
changes  to  the  unblinded  keys  associated  to  every  node  along  the  path  to  the  root.  Using  a  multicast  message,  GM  will  send 
the  corresponding  sequence  of  unblinded  keys  to  all  members  of  the  group  so  that  they  can  update  their  view  of  the  tree  and 
correctly  compute  the  new  group  key. 

9.3.2  Terms 

Because  OFT  relies  on  non-standard  data  structures,  at  least  as  far  as  cryptographic  protocols  are  concerned,  we  will  need 
to  extend  our  notion  of  terms  and  their  typing  rules.  We  will  not  need  to  modify  MSR’s  execution  rules.  In  this  section,  we 
formalize  their  syntax  and  define  their  typing  semantics. 


Syntax 

To  formalize  OFT,  we  need  to  extend  allowed  atomic  messages  with  a  limited  number  of  tags,  which  we  will  use  to  signal 
the  meaning  of  messages  sent  to  group  members.  We  also  include  node  symbols,  written  n,  which  we  will  use  only  in  a  few 
of  the  memory  predicates  maintained  by  the  group  manager.  Three  new  syntactic  categories  are  needed:  natural  numbers  ( d ) 
written  in  unary  notation,  blinded  keys  ( k '),  and  unblinded  keys  (/::).  A  blinded  key  k'  is  obtained  by  applying  a  fixed  one-way 
function  g  to  an  unblinded  key  k.  Unblinded  keys  are  either  atomic  symbols,  which  we  write  k,  or  are  obtained  by  applying 
a  fixed  mixing  function  f  to  two  unblinded  keys. 


Atomic  messages:  a 

::=  A 

(Principal) 

kAB 

( Shared  key) 

join  |  welcome  |  newkey  |  rekey  |  evict  | 

newkey'  |  shift  (Tag) 

1  n 

C Node ) 

Natural  numbers:  d 

::=  z 

(Zero) 

1  s  (d) 

( Successor ) 

Unblinded  keys:  k 

::=  k 

(Elementary  key) 

i 

( Mixing ) 

Blinded  keys:  k' 

■■■=  g  (k) 

(Blinding) 

For  convenience,  we  will  assume  that  the  mixing  function  f  is  commutative  and  that  it  has  a  unit  that  we  will  write  as  *. 
Although  more  specific  than  the  OFT  documentation  f6j,  it  is  consistent  with  the  practice  of  using  XOR  as  f,  so  that  *  can  be 
taken  to  be  the  zero  bitstring. 

Besides  atomic  messages,  keys  (now  including  blinded  and  unblinded  keys),  concatenation  and  symmetric -key  encryp¬ 
tion,  we  allow  a  term  to  be  obtained  by  encrypting  another  term  using  a  blinded  key.  Types  are  extended  with  primitive 
types  to  classify  tags,  natural  numbers,  nodes,  and  blinded  and  unblinded  keys.  The  resulting  syntax  for  terms  and  types  is  as 


follows: 

Messages:  t  ::=  a 

(Atomic  messages) 

1  k 

(Keys) 

d 

(Natural  numbers) 

t\  f 2 

(Concatenation) 

{^}k  AB 

(Symmetric-key  encryption ) 

I  {1% 

( Blinded-key  encryption) 
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Types:  r  principal  |  shKAB  (Principals  and  shared  keys) 


tag 

(Tags) 

nat 

(Natural  numbers) 

node 

(Nodes) 

uKey 

(Unblinded  keys) 

bKey 

(Blinded  keys) 

We  introduce  a  new  state  predicate  !N(f)  to  express  the  multicast  of  messages  to  multiple  group  members.  Just  like  regular 
network  messages,  we  will  use  it  in  the  state  of  the  computation  and  inside  rules. 

States:  S  ::=  •  |  S,  N(f)  |  S,  L ,(F)  |  S ,  M A(f) 

S,  !N(f)  (Multicast  network  predicate) 


Typing 

The  typing  rules  for  the  syntactic  entities  added  to  the  language  are  easily  defined.  Tags,  natural  numbers  and  both  types  of 
new  keys  are  subsorts  of  msg  (nodes  are  not  because  they  are  used  in  internal  data  structures  and  never  sent  on  the  network). 

- ss_tag  - ss_nat  - ss_uk  - ss_bk 

tag  ::  msg  nat  ::  msg  uKey  ::  msg  bKey  ::  msg 

They  are  typable  in  any  signature,  and  so  are  nodes. 

- ttp_tag  - ttp_nat  - ttp_uk  - ttp_bk  - ttp_bk 

X  h  tag  X  h  nat  X  h  uKey  X  h  bKey  X  h  node 

The  typing  rule  for  blinded-key  encryption  is  unsurprising: 

X  h  t:  msg  X  h  k  :  bKey 

- mtp_uke 

X  h  {|t|}fc  :  msg 

The  following  typing  rules  express  the  expected  typing  relations  for  the  constructors  of  natural  numbers  and  blinded  and 
unblinded  keys. 

X  I-  d  :  nat  X  h  k\  :  uKey  X  h  k'2  :  uKey 

- mtp  z  -  mt p  s  - mtp_f 

X  h  z  :  nat  X  h  s{d)  :  nat  X  h  f(k'1,k'2)  :  bKey 

Multicast  messages  are  typed  similarly  to  normal  (unicast)  network  messages. 

X  h  t  :  msg 

-  ptpJnet 

X  HN (t) 

The  typing  rules  of  other  constructs  are  as  in  the  rest  of  this  document. 

9.3.3  Data  Structures 

Both  the  group  manager  GM  and  the  group  members  need  to  maintain  data  structures  to  support  OFT.  Because  these  data 
structures  extend  beyond  the  sessions  of  a  single  (sub)protocol,  we  rely  on  memory  predicates  to  express  them  in  a  relational 
fashion.  As  will  become  apparent  shortly,  principals  will  also  use  memory  predicates  to  process  these  data  structures  in  a 
recursive  manner. 

Observe  that,  in  Section[8]  the  intruder  memory  predicate  I  was  used  both  to  hold  intruder  data  and  to  process  it.  There, 
memorized  messages  were  independent  from  each  other,  yet  the  structure  of  the  messages  in  the  intruder  memory  predicate 
drove  the  recursive  procedures  to  take  them  apart. 


X  h  k  :  bKey 

-  mtp_g 

X  h  g(fc)  :  uKey 
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Group  Manager 

The  group  manager  relies  on  the  following  three  memory  predicates  to  represent  the  OFT  tree  in  a  relational  way. 

RootcM  (n)  Node  n  is  the  root  of  the  tree 

NodecM  (n,  k ,  np)  Node  n  has  key  k  and  parent  np 

MembercM  (n,  d,  A)  Member  A  occupies  node  n  at  depth  d 

The  memory  predicate  RootGM(n)  designates  node  n  as  the  root  of  the  tree.  The  memory  predicate  NodeGM(«,  k,  np) 
expresses  the  relation  linking  every  node  n  to  its  parent  np  in  the  tree,  and  also  records  the  unblinded  key  k  associated  with 
n.  We  will  maintain  the  invariant  that  this  structure  is  indeed  a  tree. 

The  group  managers  maintains  an  instance  MembercM (n,  d,  A)  for  each  leaf  n  in  the  tree.  It  records  the  member  A 
associated  with  it.  For  convenience,  we  also  keep  track  of  its  depth  d  in  the  tree  (where  the  depth  of  the  root  is  z).  We  will  not 
store  members  at  the  root  of  the  tree  (i.e.,  the  state  will  never  contain  a  predicate  instance  of  the  form  MembercM  in.  z,  A)  for 
any  n  and  A). 

Group  Members 

Each  member  A  keeps  track  of  the  current  group  key,  of  its  own  depth  in  the  tree,  and  for  each  node  n  from  its  own  position 
in  the  tree  to  the  root,  it  maintains  the  unblinded  key  k  associated  with  that  node  and  the  blinded  key  k'  of  its  (left  or  right) 
sibling  —  it  has  no  information  about  any  other  node  in  the  tree.  This  is  achieved  through  the  following  memory  predicates: 

GroupKey^fT’)  The  current  group  key  is  k 

Depthyl((i)  A  lives  at  depth  d 

TreeView^d,  k ,  kr)  The  node  at  depth  d  on  a  path  to  the  root  has 

unblinded  key  k  and  its  sibling  has  blinded  key  k' 

Observe  that  members  do  not  have  access  to  node  identifiers.  Instead,  they  refer  to  nodes  on  a  path  to  the  root  through  their 
depth. 

Just  as  for  GM’s  view,  no  group  member  lives  at  depth  z. 

9.3.4  Joining  the  Group 

When  a  new  member  joins  the  group,  the  group  manager  expands  the  tree  by  splitting  a  current  leaf  node:  a  new  inner  node 
is  added  whose  children  host  the  joining  member  and  the  displaced  member.  Both  are  given  a  new  (unblinded)  key  and,  each 
key  on  the  path  to  the  root  is  updated.  Then,  the  group  manager  sends  a  unicast  message  to  the  new  member  informing  her  of 
the  unblinded  keys  of  all  the  nodes  to  the  root  and  of  the  blinded  key  of  their  siblings,  so  that  she  can  create  her  TreeView.  It 
also  send  a  multicast  message  to  the  entire  group  to  inform  existing  members  of  changes  to  the  keys  on  their  path  to  the  root. 
These  members  will  then  update  relevant  portions  of  their  TreeView. 

Although  intuitively  simple,  the  overall  join  protocol  is  fairly  complicate  as  different  principals  perform  distinct  actions, 
it  manipulates  recursive  data  structures  (trees  and  tree  views),  and  it  must  handle  special  cases.  We  will  first  describe  the 
actions  of  the  group  manager,  then  of  the  joining  principal,  then  the  common  actions  of  all  existing  members,  then  the  actions 
specific  to  the  displaced  member,  and  finally  specific  actions  of  the  other  existing  members. 

Group  Manager 

For  simplicity,  we  assume  that  the  group  manager  GM  starts  the  joining  protocol  upon  receiving  the  message  N(join  A).  In 
actuality,  there  will  be  some  kind  of  vetting  mechanism  that  involves  authentication  and  authorization  of  A’s  request.  We  first 
concentrate  on  the  case  where  the  tree  is  not  empty.  GM  needs  to  perform  the  following  actions: 

•  Select  a  member  B  to  displace  from  leaf  node  n; 

•  create  new  nodes  ua  and  ub  for  A  and  B  respectively; 
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•  update  the  tree  so  that  n  is  the  parent  of  nA  and  n/>; 

•  create  new  unblinded  keys  kA  and  /.: n  for  A  and  B  respectively  and  record  them; 

•  update  the  keys  associated  with  every  node  on  a  path  from  n  to  the  root  of  the  tree. 


We  will  model  the  last  item  below  with  dedicated  rewrite  rules.  In  order  to  do  so,  GM  relies  on  another  memory  predicate: 

UpdateTreeGM  (n,  A1  d ,  M 4 ,  Mm)  Update  the  path  from  node  n  at  depth  d  to  the  root, 

sending  welcome  message  Ma  to  joining  member  A 
and  update  message  Mm  to  existing  members. 


The  above  sequence  of  actions  is  captured  by  the  following  anchored  rule.  Notice  that  it  picks  the  displaced  member  B  at 
random  and  prepares  for  updating  the  path  from  the  n  to  the  root. 


/ 


VA,  B  :  principal. 
Vd  :  nat. 

Vn,  np  :  node. 

Vk  :  uKey. 


N(join  A) 

Member^  (n,  d,  B) 
NodecM(tt,  k,  np) 


V 


3k a  ■  uKey. 
3 :  uKey. 
3ua  '■  node. 
3 ns  '■  node. 


NodeGM  (nA,kA,n)  \ 

MemberGM(tiA,s(d),  A) 

NodeGM  {nB,kB,n) 
MemberGM(nB,s(d),  B ) 

NodeGM(n,  f(g(kA),  g  (kB)),np) 
UpdateTreeGM(n,  A,  d, 

(s(d),  kA,  g Ob)), 
{|newkey,/cB,  g(kA)\}k)J 


Observe  that  the  key  associated  to  node  n  is  replaced  with  the  unblinded  key  f(g (kA),  g (fee))  obtained  from  the  new  keys  kA 
and  kB  associated  with  114  and  hb  respectively.  In  the  UpdateTreeGM  predicate,  the  welcome  message  for  A  is  initialized 
to  the  depth  s (d)  of  her  node,  her  new  (unblinded)  key  kA  and  the  blinded  key  g ( k « )  of  her  sibling.  The  update  message  to 
the  other  members  of  the  group  is  initialized  to  just  B's  new  key  kB  together  with  A’s  blinded  key  g (kA)  and  tag  newkey,  all 
encrypted  with  the  key  k  that  was  originally  associated  with  n,  the  node  on  which  B  was  sitting  (so  that  only  B  can  decrypt 
this  message). 

Before  we  examine  how  the  rest  of  the  welcome  and  update  messages  are  constructed,  let  us  settle  the  special  case  where 
A  is  the  first  member  of  the  group,  and  is  therefore  starting  from  an  empty  tree.  In  this  case,  the  group  manager  simply  create 
a  new  node  114  and  key  kA  for  A  and  send  her  a  welcome  message  which  includes  her  key  and  an  arbitrary  value  (here  *)  for 
the  blinded  key  of  the  nonexistent  sibling  node  of  114 . 

VA  :  principal. 

Vn  :  node. 

VfcGM,A  :  shKGM  A. 


N(join  A) 
RootGM(n) 


3  kA 
3  nA 


uKey. 

node. 


NodeGM  (nA,  kA,  n) 
MemberGM(nA,s(z),  A) 

N({welcome,  kA,  *}kGU,A)/ 


The  memory  predicate  UpdateTree  is  used  by  GM  for  the  purpose  of  updating  the  keys  of  the  nodes  on  a  path  from  the 
displaced  member  to  the  root  of  the  tree,  and  once  the  root  has  been  reached  to  send  the  welcome  and  update  messages.  The 
following  two  rules  travel  this  path  towards  the  root. 

The  first  rule  is  concerned  with  an  inner  node  n  at  depth  s (d)  on  this  path.  It  recomputes  the  keys  of  the  parent  node  np  on 
the  basis  of  the  key  k  of  n  (recomputed  at  the  previous  iteration)  and  the  key  ks  of  its  sibling  ns.  The  welcome  message  to  the 
joining  member  A  is  extended  with  the  blinded  key  g ( ks )  of  ns,  while  the  update  message  to  existing  members  is  extended 
with  the  blinded  key  g(fc)  of  n,  tagged  and  encrypted  with  ks  (remember  that  n  is  the  sibling  of  ns ).  This  makes  n’s  new 
blinded  key  available  to  all  the  members  in  ns’s  subtree. 


/VA  :  principal. 

VkQM.A  ■  shK  GM  A. 
Vd  :  nat. 

Vn,ns,np,npp  :  node. 
Vfc,  kp,  ks  :  uKey. 
\VMA,Mm  :  msg. 


UpdateTreeGM(n,  A,  s (d),  MA,  Mm ) 
Nod  eGM(n,k,np) 

NodeGM  {np,  kp,  npp) 

Nod  eGM(ns,ks,np) 


UpdateTreeGM(np,  A,  d,  \ 

(Ma,  g (ks)), 

({| rekey,  g(fc)|}fcs,  Mm)) 
Nod  eGM(n,k,np) 

Nod  ecM(ns,ks,np) 

NodeGM(?rp,  f(g(fc),  g  (fcs))  ,  tipp)  J 


GM 
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When  the  root  (the  node  n  at  depth  z)  has  been  reached,  GM  sends  the  welcome  message  MA  to  A  by  encrypting  it  and  an 
acknowledgment  tag  with  the  key  Ucm,a  shared  between  them.  It  also  broadcasts  the  updated  message  Mm  to  all  existing 
members 


X  GM 

N ({welcome,  MA}kGUA) 

!N  (Mm) 

Recall  that  the  memory  predicate  UpdateTree(n,  A ,  d ,  M a  ,  Mm)  obeys  the  invariant  that  d  is  the  depth  of  node  n. 

If  the  node  nA  where  A  is  installed  is  at  depth  d,  GM  sends  her  a  single  unicast  message  {welcome,  M a } kGU  A  of  size 
proportional  to  d ,  and  it  sends  one  broadcast  message  rekey,  Mm,  also  of  size  proportional  to  d. 


N A  :  principal. 

VA-gm ,a  :  shK  GM  A. 
Vn  :  node. 

\\/MA,Mm  :  msg. 


UpdateTreeGM(n,  A ,  z,  MA,  Mm) 


Joining  Member 

The  actions  of  the  joining  member  A  consist  in  sending  a  join  request,  receiving  the  welcome  message,  and  processing  it. 
This  is  realized  by  the  following  two-rule  role  (the  memory  predicate  ReverseJoin.i  is  discussed  below): 


/  3L  :  principal  x  tag. 


— ► 

N(join  A) 

L{A) 

Md  :  nat.  N({welcome,  MA}kQU  A) 

\VM  :  msg.  L(A) 

ReverseJoin^  (Ma)j 

As  mentioned  earlier,  we  do  not  model  the  vetting  of  A’s  request.  Consequently,  we  do  not  consider  a  denial  subprotocol. 

Upon  receiving  the  welcome  message  M 4,  the  joining  member  A  relies  on  the  following  two  memory  predicates  to 
process  it. 

ReverseJoin^M)  Reassociate  message  M 

CreatePathyi((I,  M)  Create  A’s  tree  view  from  depth  d  with  message  M 

The  nesting  of  the  concatenation  operators  in  the  welcome  message  MA  is  the  opposite  of  what  A  needs.  Therefore  she  first 
reverses  it  using  a  subprocedure  driven  by  ReverseJoin. 

(VX,  Y,  Z  :  msg.  ReverseJoin/i((X,  Y),  Z)  — >  ReverseJoin^X,  (Y,  Z))))^A 

Once  the  welcome  message  has  been  fully  reassociated,  its  leftmost  component  has  the  form  (s (d),  kA ,  k's)  where  s (d)  is 
the  depth  of  A’s  new  node,  kA  is  its  unblinded  key,  and  k's  is  the  blinded  key  of  its  sibling.  She  can  therefore  create  a  new 
TreeView  element  for  her  node  and  set  her  depth.  She  also  defines  the  memory  predicate  createPath A(d,  M)  which  will 
allow  creating  TreeView  elements  for  the  rest  of  the  path  to  the  root,  where  d  is  the  depth  of  the  next  node  to  process. 

(Vd  :  nat.  TreeViewA(s(d),  kA,  k's) 

MkA  :  uKey.  ReverseJoin^((s(d),  kA,  k's),  M )  — >•  Depth  4(s(d)) 

\/kg  :  bKey.  CreatePath^ (d,M) 


While  processing  the  memory  predicate  CreatePath^ (d,  M),  the  joining  principal  A  maintains  the  invariant  that  she  has 
memorized  the  unblinded  keys  at  depths  below  d  in  TreeView  predicates.  The  blinded  keys  of  the  siblings  of  the  remaining 
nodes  to  the  root  will  be  found  in  M. 

The  first  rule  for  CreatePath  processes  an  inner  node  n,  whose  depth  is  therefore  s(d)  for  some  d.  It  has  just  stored  the 
key  k  of  n’s  child  on  a  path  to  A  in  a  TreeView  predicate,  and  it  finds  the  blinded  key  /,:{  of  n’s  sibling  at  the  head  of  what 
is  left  of  the  reversed  welcome  message.  It  then  simply  creates  a  TreeView  for  n  on  the  basis  of  /.;{  and  k  and  calls  itself 
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recursively  on  the  remainder  of  the  message. 


Nd  :  nat. 

Vfcc  :  uKey.  CreatePath^(s(d),  {k's ,  M )) 
Vfc',/c'  :  bKey.  TreeView^  (s(s (d)),kc,k'c) 
\VM  :  msg. 


CreatePath^d,  M) 
TreeViewA(s(d),  f(g(fcc),  k'c),  k's) 
TreeView,4(s(s(d)),  kc,  k'c) 


The  recursion  ends  upon  reaching  the  root:  the  depth  in  CreatePath  is  z  and  there  is  nothing  left  of  the  welcome  message. 
Then,  A  uses  the  same  procedure  to  construct  the  group  key. 


fVkc  :  uKey.  CreatePath^(z,  •) 

:  bKey.  TreeViewJ4(s(z),  kc,  k'c) 


GroupKeyj4(f (g(A:c),  fc'))\ 
TreeView^  (s(z),  kc,  k'c)  ) 


Altogether,  A  has  sent  one  message  (the  join  request)  and  received  one  unicast  message  from  GM  of  length  proportional  to 
d,  where  d  is  her  depth  in  the  tree.  Processing  this  response  involves  2d  rule  applications. 


Existing  Members  —  part  I 

The  existing  members  of  the  group  process  the  update  message  Mm  broadcast  by  the  group  manager  by  copying  it  in  a  private 
UpdateTreeView  memory  predicate.  This  is  achieved  by  the  following  rule: 

(vMm:mss.  <N  (M„.) 

Observe  that  we  implement  multicast  by  reading  the  message  !N(Mm)  and  then  retransmitting  it.  As  we  said,  each  existing 
member  C  makes  use  of  the  auxiliary  memory  predicate 

U  pdateT  reeViewc.  ( M)  Update  the  tree  view  on  the  basis  of  message  M 

Upon  saving  the  update  message,  the  displaced  member  B  and  other  existing  members  C  process  this  message  differently. 

Just  like  the  welcome  message  for  the  joining  member,  the  update  message  is  associated  in  the  wrong  way.  The  following 
rule  reassociates  it. 

(WX,Y,Z  :  msg.  UpdateTreeViewc((X,  Y),  Z)  — >  UpdateTreeViewc(X,  (Y,  Z))))VC 


Displaced  Member 


The  group  member  B  that  has  been  displaced  will  find,  as  the  first  component  of  the  update  message,  a  term  {|newkey,  knew, 
Kiev)  |}fc  encrypted  with  the  key  k  of  the  node  at  the  current  depth  d  of  B.  This  informs  him  that  knew  is  his  new  key  (at  depth 
s (d))  and  k'new  is  the  blinded  key  of  its  sibling  (the  joining  member).  On  the  basis  of  this  information,  he  will  create  a  new 
TreeView  for  his  new  deeper  node,  and  trigger  a  recalculation  of  the  key  of  all  the  nodes  on  his  path  to  the  root.  This  is  done 
by  defining  the  memory  predicate  RekeyB(d),  whose  processing  rules  are  given  below  under  “Existing  Members  —  part  II”. 
The  rest  of  the  update  message  is  discarded  since  B  has  all  the  information  he  needs  to  update  the  key  chain. 


Nd  :  nat. 
Vfc  :  uKey. 
Vfc'bKey. 
\fJM  :  msg. 


UpdateTreeViews({|newkey,  knew,  k'new§k,  M) 
TreeViews((i,  k,  k's) 

DepthB(d) 


-» 


TreeViewB(s(d),  knew,  k'new)\ 
TreeView B(d,  k,  k's) 
Depths(s(c?)) 

Rekeys(d)  ) 


Altogether,  B  receives  one  (multicast)  message  of  length  proportional  to  the  depth  of  his  node  in  the  tree.  The  key  update 
performed  through  Rekey  has  cost  proportional  to  d. 
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Other  Existing  Members 

For  all  other  existing  group  members,  the  update  message  will  contain  an  updated  blinded  key  for  the  siblings  of  an  initial 
segment  of  their  path  to  the  root.  In  order  to  act  on  it,  they  first  need  to  discard  prefixes  that  are  irrelevant  to  them.  This  is 
achieved  by  the  following  simple  rule: 

(VX,M  :  msg.  UpdateTreeViewc.(X,  M)  — >  UpdateTreeViewc(M))VC 

When  such  a  member  C  sees  the  first  UpdateTreeView  message  whose  contents  has  the  form  ({|/4|}fc,  ^0  f°r  a  known  key 
k  (i.e.,  one  that  is  found  in  a  TreeViewc  predicate),  he  knows  that  it  contains  a  new  blinded  key  k's  for  the  sibling  of  the 
corresponding  node.  Then,  C  updates  this  TreeView  element  and  prepares  for  a  rekey  at  depth  d.  The  rest  of  the  update 
message,  M,  is  discarded. 

Nd,  :  nat.  \  VC 

Vfc  :  uKey.  UpdateTreeViewc({| rekey,  k!a ,  |}fc  M)  TreeViewc(s((i),  k,  k's ) 

VK>Kid  :  bKey.  TreeViewc(s(d),  k,  k'old)  Rekeyc(d) 

\VM  :  msg.  J 

Note  that,  as  written,  a  member  may  discard  relevant  message  fragments  using  the  rule  shown  under  “Existing  Members  — 
part  I”  before  applying  this  rule.  This  would  produce  an  incorrect  tree  view.  For  the  sake  of  simplicity,  we  leave  this  point  of 
non-determinism  open  in  our  specification,  as  a  correct  description  would  be  significantly  more  complex. 

Just  like  the  displaced  principal,  other  existing  members  receive  one  multicast  message  of  length  proportional  to  the  depth 
d  of  the  insertion,  and  need  to  do  an  amount  of  work  that  is  proportional  to  d.  However,  this  work  is  variously  split  between 
discarding  message  components  and  rekeying. 


Existing  Members  —  part  II 


Rekeying  is  performed  by  all  existing  group  members.  It  is  triggered  by  inserting  a  memory  predicate  of  the  form 

Rekey  c(d)  Rekey  the  path  to  the  root  from  depth  d 


in  the  state.  It  is  implemented  by  the  next  two  rules.  The  outcome  will  be  to  update  all  TreeViewp  elements  at  depth  d  and 
smaller  with  the  value  of  their  current  key.  The  new  group  key  is  obtained  upon  reaching  the  root  of  the  tree. 

Recall  that  no  TreeView  is  defined  for  depth  z.  The  next  rule  operate  under  the  invariant  that,  when  processing  Rekeyc(s(d)), 
all  TreeView  elements  of  C  are  accurate  at  depths  greater  than  s (d)  but  not  at  depths  s(d)  and  lower.  In  particular,  TreeView^ 
exists  and  is  accurate  for  the  node  n'  at  depth  s(s (d)),  but  not  for  the  node  n  at  depth  s (d).  The  rule  recomputes  the  key  of  n 
by  combining  the  correct  key  k  of  n'  with  the  (also  correct)  blinded  key  k'  of  n’s  sibling  —  this  new  key  has  value  f(g(fc),  k'). 

It  then  calls  itself  recursively  on  depth  d. 

\/d :  nat.  Rekeyc(s(d))  Rekeyc(d) 

Vfc,  koid  ■  uKey.  TreeViewc(s(s(d)),  k,  k')  —y  TreeViewc(s(s(d)),  k,  k') 

Mk',k'p  :  bKey.  TreeViewc(s(d),  kaid,  kp)  TreeViewc(s(d),  f(g(k),  k'),  kp) 

Once  the  root  is  reached,  the  group  key  is  updated  on  the  basis  of  the  keys  of  the  element  just  below  it. 


(Vd  :  nat.  Rekeyc(z) 

VAt,  k0id  :  uKey.  Group  Key  c{k0id) 

Vfc':  bKey.  TreeViewc(s(z),  k,  k') 


GroupKeyc(f(g  (k),k')) 
TreeViewc(s(z),  k,  k') 


vc 


9.3.5  Eviction 

When  evicting  a  group  member  member  A,  the  corresponding  leaf  node  ha  is  removed  and  the  tree  is  compacted  so  that  its 
sibling  ns  becomes  its  parent.  It  is  also  necessary  to  change  the  blinded  key  of  ns  so  that  A  has  no  usable  information  about 


90 


9  EXAMPLES 


the  tree  she  has  been  evicted  from.  To  do  so,  the  group  manager  gives  a  new  unblinded  key  to  some  arbitrary  member  B  in 
the  subtree  starting  at  ns.  It  then  informs  all  members  in  this  subtree  that  they  must  update  their  view  of  the  tree  (since  their 
path  to  the  root  has  been  shortened  by  one  node)  and  perform  the  rekeying  operation.  The  other  group  members  need  to  just 
do  the  re  keying. 


Group  Manager 


From  the  group  manager’s  perspective,  the  eviction  protocol  resembles  the  joining  protocol,  but  is  slightly  more  involved  as 
the  tree  below  the  evicted  member’s  sibling  must  be  handled  differently  from  the  other  remaining  members.  Altogether,  the 
operation  will  make  use  of  the  following  private  memory  predicates: 


Evicts  (A) 

PickMemberGM(n,  d,  d ) 
UpdateTree2GM(n,  d.  d,  M) 
UpdateTree3GM(n,  M) 
ShiftUpGM(n) 


Evict  member  A 

Pick  a  member  to  rekey  underneath  node  n 

Update  the  path  from  node  n  at  depth  d  to  the  root  sending  update  message  M  to  members 
Update  the  path  from  node  n  to  the  root  sending  update  message  M  to  members 
Decrement  the  depth  of  leaves  under  n  by  one 


Assume  that  the  decision  of  evicting  member  A  has  resulted  in  the  addition  of  the  memory  state  predicate  EvictGM(  A). 
Carrying  out  this  decision  consists  of  several  operations:  sending  an  eviction  message  to  A,  removing  her  node  and  com¬ 
pacting  the  tree,  updating  the  keys  in  the  tree,  and  notifying  the  remaining  members  through  multicast.  The  following  rule 
immediately  does  the  first  three  operations,  and  prepares  for  the  remaining  two  (which  require  visiting  the  tree).  The  memory 
predicate  PickMemberGM(ns,  s(d),  s(z) )  prepares  to  pick  a  member  under  the  former  sibling  node  ns.  The  value  s(z)  will  be 
used  to  change  mode  of  operation  on  the  way  back,  while  s (d)  serves  the  purpose  of  informing  members  in  this  subtree  of 
which  node  to  eliminate  in  their  view. 


/ 

V 


VA  :  principal. 

V&gm.a  :  shK  GM  A. 

V  ft ,  Tig ,  Tip  ,  Tipg ,  Tt'pp  .  node. 
Vfc,  ks,  kp,  kps  :  uKey. 


EvictGM(A) 
MemberGM(n,  s (d),  A) 
NodeGM(n,  k,np) 

Nod  eGM(ns,ks,np) 
NodeGM (ftp,  kp,  Tipp ) 


,  GM 

N({evict}fcGM  J 
NodeGM(ns,fcs,npP) 
PickMemberGM(ns,  s(d),  s(z)) 


GM  follows  an  arbitrary  path  to  a  leaf  starting  at  the  sibling  of  the  evicted  node.  Whenever  it  follows  a  branch,  it  uses  the 
memory  predicate  ShiftUp  to  also  start  a  parallel  procedure  to  shift  every  depth  value  in  the  subtree  that  was  not  followed. 


/Vn,  ns,  Tip  :  node. 
Vfc,  ks  :  uKey. 

Vci,  d  :  nat. 

\VM  :  msg. 


PickMemberGM(A.p,  d,  d') 
NodeGM(n, k,np) 

Nod  eGM(ns,kg,np) 


PickMemberGM(n,  d,  s(d'))\  GM 
NodeGM (n, k,  np) 

Nod  eGM(ns,k3,np) 

ShiftUpGM(ns)  ) 


When  a  leaf  n  corresponding  to  member  B  is  reached,  GM  creates  a  new  key  k,  updates  IPs  information,  notifies  him  of  the 
change,  and  prepares  for  a  rekey  using  procedure  UpdateTree2. 


NB  :  principal. 

VfcG m,b  :  shK  GM  B. 
Vd,  d  :  nat. 

Vn,  Up  :  node. 

Mkoid  :  uKey. 

\VM  :  msg. 


PickMemberGM(n,  d,  s(d')) 
MemberGM(?r,  s (d),  B) 

Nod  eGM(n,k0id,np) 


3k  :  uKey. 


S  GM 

MemberGM(n,  d,  B) 

NodeGM(n,  k,  np) 

UpdateTree2GM(np,  d' ,  d, 

{newkey',  J,fc}fcGMB) 


The  procedure  UpdateTree2  is  similar  to  UpdateTree  in  the  joining  protocol,  except  that  no  joining  member  nor  welcome 
message  are  involved.  It  grows  the  update  message  to  the  remaining  members  with  information  so  that  the  nodes  under  this 
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tree  can  shorten  the  view  of  their  path  to  the  root  of  the  tree  and  perform  a  rekey. 


Nd:d  :  nat.  UpdateTree2GM(n,  d,  s(d'),  M) 

\/n,ns,np,npp  :  node.  NodeGM (n,k,np) 

V /c,  kp ,  ks  .  u  Key .  N  odeGM ( tip  ,  kp , 

\VM  :  msg.  NodeGM(ns,  fcs,  np) 


UpdateTree2GM(np,  d,  d',  (M,  {(shift,  d,  g(fe)|}fc»))\ 
NodeGM(n, 

NodeGM(ns,  ks,np) 

NodeGM(np,  f(g(fe),  g  (ks)),npp)  ) 


When  the  (parent  of  the)  evicted  node  is  reached,  it  shifts  to  procedure  UpdateTree3GM  which  behave  similarly,  except  that 
the  update  message  will  be  extended  only  with  a  rekey  instruction. 


Vn  :  node. 

Vd :  nat.  UpdateTree2GM(n,  z,  d,  M)  -» 
VM  :  msg. 


GM 


UpdateTree3GM(n,  M) 


I'id  :  nat.  UpdateTree3GM(n,  M) 

Vn,ns,np,npp  :  node.  NodeGM(rJ,  k,  np) 
\/k,kp,ks  :  uKey.  NodeGM  (np,  /cp,  npp) 
\VM  :  msg.  NodeGM(ns,  fcs,  np) 

When  reaching  the  root,  GM  broadcasts  the  update  message. 


UpdateTree3GM(?rp,  (M,  {( rekey,  g(fe)|}fcJ)\ 
NodeGM(n,  k,np) 

NodeGM(ns,ks,np) 

NodeGM(np,  f(g(/c),  g(ks)),  npp)  ) 


Vn  :  node.  UpdateTree3GM(n,  M)  !N(M)  \ 

VM  :  msg.  RootGM(n)  '  RootGM  (n) J 


The  procedure  triggered  with  memory  predicate  ShiftUpGM  simply  traverses  a  subtree  all  the  way  down  to  its  leaves, 
where  it  decrements  the  depth  of  every  member  by  one. 


( 

Vn,  nj,  nr  :  node. 
Vfc; ,  hr  :  uKey. 

V 


ShiftUpGM(n) 

Nod  eGM(ni,ki,n) 
NodeGivi(?rr-,  kr,  n) 


(Vn  :  node. 

\/d  :  nat. 

VA  :  principal. 


ShiftUpGM(n) 
MemberGM(n,  s (d),  A) 


ShiftUpGM(ni)  \ 
ShiftUpGM(nr.) 

NodeGM(n;,fc;,n) 

NodeGM(nr,fcr,n)/ 

\  GM 

MemberG|vi(?t,  d.  A) 


Evicted  Member 


Upon  receiving  an  eviction  message,  the  evicted  member  A  removes  her  depth  predicate  and  sets  the  memory  predicate 
Destroy  Path  A(d)  which  she  will  use  to  dispose  of  all  the  path  elements  associated  with  this  group. 


(VkoM'A  :  shK  GM  A.  N({evict}feGM  A) 
\Wd  :  nat.  DepthA((f) 


DestroyPath^(ri) 


VA 


The  auxiliary  predicate  is  read  as  follows. 


DestroyPath  A(d)  Dispose  of  data  structures  at  depth  d  and  below 


A  gets  rid  of  her  TreeView  elements  one  at  a  time,  and  eliminates  the  group  key  when  she  reaches  the  root. 


Nd  :  nat. 

I  Vfc  :  uKey. 
\yk'  :  bKey. 


DestroyPath^  (s(d)) 
TreeView,4(s((i),  k,  k') 


VA 


DestroyPathj4(d) 


Vfc  :  uKey. 


DestroyPathA(z) 


-A 


VA 


GroupKeyyl(fc) 

From  A’s  perspective,  eviction  involved  receiving  one  message  and  applying  d  rules  where  d  was  her  depth  in  the  tree. 
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All  Members  —  part  I 

Just  like  in  the  joining  protocol,  existing  members  receive  the  multicast  update  message  in  their  UpdateTreeView  memory 
predicate  and  reassociate  it. 


Rekeyed  Member 

The  rekeyed  member  B  replaces  his  key  k0m  with  the  new  key  k  from  the  GM.  It  invokes  the  procedure  Rekey'c(d,  d)  to 
rekey  the  segment  of  its  path  to  the  root  from  depth  d  to  the  depth  d  of  the  evicted  node. 

/V/cgm.b  :  shK  GM  B.  _  \  VB 

Vd,  d  :  nat.  UpdateTreeViewB({newkey',  d,  k}kGM  B ,  M)  Rekey'B  (d,d) 

\/k,k0id  ■  uKey.  TreeViews(s(s(d)),  kQid,  k')  TreeViews(s(s(d)),  k,  k') 

\Vfc'  :  bKey.  J 


Members  in  Upshifted  Subtree 

The  members  in  the  subtree  that  starts  with  the  sibling  of  the  evicted  node  (the  upshifted  tree )  need  to  carry  out  two  operations: 
rekey  their  path  to  the  root  and  reduce  their  depth  by  one.  This  achieved  using  the  following  two  memory  predicates: 

Rekey'c.(d,  d)  From  depth  d,  rekey  and  shift  up  depth  d  and  then  just  rekey 
ShiftUpc.(cZ)  Decrement  the  depth  of  the  path  from  d  and  below 


When  asked  to  process  the  message  of  the  form  {|  s h  i ft ,  d ,  fc' 1}  ^  for  the  deepest  key  k  in  its  tree  view,  member  C  replaces 
the  old  blinded  key  at  that  depth  with  k!  and  then  triggers  the  procedures  Rekey'  to  update  the  blinded  keys  of  all  the  nodes 
to  its  path  to  the  root. 


Vd,  d  :  nat. 

Vfc  :  uKey. 
ykfk’old  :  bKey. 


UpdateTreeViewc({|shift,  d.  fc'l}*,,  M) 
TreeViewc(s  {d),k,k'old) 


TreeView c(d,  k,  k') 
Rekey'c(d,  d) 


vc 


The  auxiliary  predicate  Rekey'c.  updates  the  keys  of  C’s  tree  view  upwards  toward  the  root,  without  changing  their  depth.  It 
stops  at  the  depth  where  the  evicted  member  lived. 

/Vd,  J :  nat.  Rekey'c(s (d),d)  Rekey'c(d,  d)  \  VC 

Vfc,  k0id  :  uKey.  TreeViewc(s(s(d)),  k,  k')  TreeViewc(s(cs(d)),  k,  k1) 

\W,kp  :  bKey.  TreeViewc(s(d),  kQid,  k’p)  TreeViewc(s(d),  f(g(fc),  k'),  k'p) ) 

There,  it  removes  the  TreeView  element  at  that  depth,  invokes  a  regular  rekeying  of  the  nodes  from  there  up  using  Rekey  and 
triggers  the  increment  of  every  depth  below  this  element  using  the  auxiliary  predicate  ShiftUp. 


/Vd  :  nat. 

Vfc,  k0id  :  uKey. 
\W  :  bKey. 


Rekey'c(s(d),  s(d)) 
TreeViewc(s(d),  k,  k') 


Rekeyc(d) 

ShiftUpc(s(d)) 


vc 


As  it  moves  downwards,  the  predicate  ShiftUpC7(d)  decrements  the  depth  of  every  TreeView  element  it  finds,  as  well  as 
the  depth  of  member  C  when  it  reaches  it. 


Vd  :  nat. 
Vfc  :  uKey. 
Vfc'  :  bKey. 


ShiftUp4(d) 
TreeView^ (s(d),  fc,  k') 


-> 


ShiftUpA(s(d)) 
TreeView^(d,  fc,  fc') 


v^t 


^Vd  :  nat. 


ShiftUp^  (s(d)) 
Depth4(s(d)) 


-> 


Depthj4(d) 


MA 
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All  Members  —  part  II 

At  this  point,  all  members  perform  the  rekey  operation  just  as  in  the  joining  subprotocol.  Members  in  the  upshifted  tree 
continue  from  where  Rekey'  left  off,  while  other  members  do  it  from  scratch. 


10  Conclusions 

This  report  collects,  rationalizes  and  completes  a  body  of  previously  published  work  on  the  MSR  2.0  cryptographic  protocol 
specification  language.  In  the  past,  we  had  published  aspects  of  this  research,  but  never  in  a  single  place  and  not  always  using 
a  consistent  syntax  or  the  same  set  of  features,  which  made  it  difficult  for  colleagues  to  get  a  full  picture  of  MSR  2.0.  In  this 
regard,  the  present  report  is  meant  to  act  as  a  reference.  It  also  contains  several  definitions  and  numerous  proofs  that  were 
never  published. 

A  variant  of  MSR  2.0,  documented  in  j24l.  extends  the  scope  of  this  language  beyond  cryptographic  protocols.  The 
main  difference  consist  in  the  ability  to  declare  symbols  (rather  than  using  hardwired  constructs  specialized  to  security 
applications),  in  the  presence  of  guards  (state  predicates  that  must  be  present  for  a  rule  to  fire  but  that  are  not  consumed), 
and  the  absence  of  data  access  validation  (a  static  check  specialized  to  cryptographic  protocol  specification).  This  variant  has 
been  implemented  using  the  Maude  rewriting  tool  lf39l . 
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A  Collected  Rules 

This  appendix  collects  the  grammatical  productions,  judgments  and  rules  used  throughout  the  report  for  the  ease  of  the  reader.  More 
specifically,  the  syntax  of  MSR  is  summarized  in  SectionpO]  and  the  rules  for  type-checking,  data  access  specification,  and  execution  are 
given  in  Sections  |A.2|  | A.3|  and| A.4[  respectively.  For  the  convenience  of  the  reader,  we  give  the  number  of  the  page  where  each  notion  is 
first  introduced. 


A.l  Syntax 


Atomic  messages: 

::=  A 

1  k 

I  n 

1  m 

( Principal ) 

(Key) 

(Nonce) 

(Raw  datum ) 

Parametric  messages:  t 

a 

I  * 

fl  t2 
{*}* 

OT* 

(Atomic  messages) 

(Variables) 

(Concatenation ) 

(Symmetric-key  encryption ) 

(. Asymmetric-key  encryption ) 

Message  tuples:  t 

1  f,  t 

(Empty  tuple) 

(Tuple  extension) 

States:  S  ::= 

1  5,  N(t) 

1  S,  L,(i t) 

S,  M A(f) 

(Empty  state) 

(Extension  with  a  network  predicate) 

( Extension  with  a  role  state  predicate) 
(Extension  with  a  memory  predicate) 

Types 

t  ::=  principal  (Principals) 
nonce  ( Nonces ) 

shKAB  (Shared  keys) 
pubKA  (Public  keys) 
privK  k  (Private  keys) 

msg  ( Messages ) 

Tuple  types 

TW  X 

(Empty  tuple ) 
t  (Tuple  type  extension) 

Predicate  sequences: 

Ihs 

|  Ihs,  N(f) 

Ihs ,  L(S) 

Ihs,  MA(t) 

( Empty  predicate  sequence ) 

(Extension  with  a  network  predicate) 
(Extension  with  a  role  state  predicate) 

( Extension  with  a  memory  predicate) 

Right-Hand  sides: 

rhs 

:=  Ihs 

3  x  :  r.  rhs 

(Sequence  of  message  predicates ) 

(Fresh  data  generation) 

Rule: 

r 

:=  Ihs  — >  rhs 

Mx  :  r.r 

(Rule  core ) 

( Parameter  closure ) 

Rule  collections: 

P 

3  L\r.p 

r,  P 

(Empty  role) 

(Role  state  predicate  parameter  declaration) 
( Extension  with  a  rule ) 

Protocol  theories: 

V 

1  v,  PWA 

V,  pA 

(Empty  protocol  theory) 

( Extension  with  a  generic  role) 

( Extension  with  an  anchored  role ) 

[p-i 


[p-Ej 

[p@ 

fp-i 

tp-HD 


[p-UD 

[p-HD 

[p-DD 

\P-m 

[p-HD 


Active  role  sets:  R 


(No  active  role) 

R,  pA  ( Extension  with  an  instantiated  role ) 


[p  UD 
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Signatures:  E  ::=  •  (Empty  signature)  [p.|4j 


E ,  a  :  t 

( Atomic  message  declaration) 

E,  U  :  t 

(Local  state  predicate  declaration ) 

IP- 

10 

E,  M_  :  t 

(Memory  predicate  declaration) 

IP- 

10 

Typing  contexts:  F 

::=  E 

(Plain  signature) 

[p- 

§ 

L  ,x:t 

(Extension  with  a  variable  declaration ) 

L  ,L:t 

(Extension  with  a  role  state  predicate  declaration ) 

[p  HD 

Knowledge  contexts:  A 

::=  ■ 

(Empty  knowledge  context) 

ip-m 

A,  a 

(Extension  with  atomic  knowledge ) 

A,x 

( Extension  with  parametric  knowledge ) 

A,  t 

(Extension  with  ground  terms) 

[p-EO 

Snapshot:  C  ::=  [S']  §  [p.[36) 

A.2  Typing  Rules 


r  ::  r' 

r  is  a  subsort  ofr' 

[P-0 

Eh  t-.T 

Term  t  has  type  r  in  signature  E 

[PP-00 

Eh  T 

r  is  a  valid  type  in  E 

Ip-0 

h  E 

E  is  a  valid  signatures 

[pp-003 

f  r 

r  is  a  valid  typing  context 

[pp.|7fT2| 

Eh  t:r 

Term  tuple  t  has  type  f  in  signature  E 

[P-0 

r  h  t 

t  is  a  valid  tuple  type  in  typing  context  L 

[P0 

Eh  P 

P  is  a  valid  message  predicate  in  signature  E 

[p-d3 

Eh  S 

S  is  a  valid  state  in  signature  E 

[p  HD 

r  F  rhs 

rhs  is  a  valid  rule  consequent  in  typing  context  F 

[p  HD 

r  h  r 

r  is  a  valid  rule  in  typing  context  T 

ip  HD 

r  h  p 

p  is  a  valid  rule  collection  in  typing  context  T 

[p  HD 

Eh? 

V  is  a  valid  protocol  theory  in  signature  E 

[p  HD 

Shi?. 

R  is  a  valid  active  role  set  in  signature  E 

[p-HD 

T  ::  t'  t  is  a  subsort  of  T1  [p.0 


-  ss_pr 

principal  ::  msg 


-  ss_nnc 

nonce  ::  msg 


-  ss_shK 

shK  A  B  ::  msg 


-  ss_pbK 

pubK  A  ::  msg 


-  ss_pvK 

privK  k  ::  msg 


Eh  t  :  T  T  h  t  :  T 


Term  t  has  type  r  in  signature  E  (viz.  context  T ) 


[ppEE 


E  h  ti  :  msg  E  h  t2  :  msg 

-  mtp  cnc 

Eh  t\tz  '■  msg 


Eh  t  \  msg  E  h  k  :  shK  A  B 

-  mtp_ske 

E  h  {t}k  :  msg 
Eh  t  \  t'  t  ::  r 

-  mtp_ss 

Eh  t-.T 


Eh  t  :  msg  Eh  k  :  pubK  A 

-  mtp_pke 

E  h  {{tjfe  :  msg 

-  mtp_a 

(E,  a  :  t,  E;)  h  a  :  r 
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E  h  T  rhr 

r  is  a  valid  type  in  signature  £  ( viz.  context  T ) 

ipp 

ttp_pr 


E  h  principal 

Eh  A  :  principal  Eh  B  :  principal 
E  h  shK  A  B 


ttp_shK 


-  ttp  nnc 

E  h  nonce 

Eh  A  :  principal 
E  h  pubK  A 


- ttpmsg 

E  h  msg 

Eh  k:  pubK  A 

- ttp_pvK 

E  h  privK  k 


h  E 


E  is  a  valid  signatures 


ipp.[5]p~n 


-  itp_dot 

h  ■ 


E  h  T  h  E 

-  itp_a 

h  E  ,a\T 


E  h  princi  pa  I ( x  t  h  E 

-  itp_rsp 

h  E,  L;  :  principal*'4'  x  t 


S  h  principal*'4'  x  t  h  E 

-  itp  mem 

h  E,  M_  :  principal*'4'  x  r 


f  r 


r  is  a  valid  typing  context 


[PP  [ZltiU 


h  e  r  h  T  F  r 

-  ctp_sig  -  ctp_x 

Is  E  F  r,a;  :  r 


r  h  principal*'4'  x  r  FT 

-  ctp_rsp 

F  r,  L  :  principal*'4'  x  r 


Eh  t  :  T  T  h  t  :  T 


Term  tuple  t  has  type  r  in  signature  E  ( viz.  context  V ) 


[pp.  9  6 


E  h  ■  :  ■ 


mtp_dot 


Eh  t  :  T  E  h  t  :  [t/x]f 

-  mtp  ext 

E  h  ( t , t)  :  x  r 


r  h  r 


t  is  a  valid  tuple  type  in  typing  context  h 


[p-EJ 


r  h  ■ 


ttp_dot 


Thr  F,a;:rhr 

-  ttpext 

r  h  t ^  x  r 


Eh  p  r  h  p 


P  is  a  valid  message  predicate  in  signature  S  ( viz.  context  T ) 


[pp.fTol|6| 


Eh  t  :  msg  (^i  L  :  t,S  )  h  J  :  r  (E,M_:r,E)h  ( A ,  t)  :  r 

-  ptp_net  -  ptp-rsp  -  ptp_mem 

E  h  N{t)  (E,L,  :f,E')  h  U(t)  (E,  M_  :  r,  S')  h  M A(t) 


s  h  5  rhfc 

S  (viz.  Ihs)  is  a  valid  state  (viz.  predicate  sequence)  in  signature  £  (viz.  context  T ) 

[pp-p~nibi 

Eh  S  Eh  P 

-  stp_dot 

- stp_ext 

S  F  ■ 

E  h  (S,P) 

r  F  rhs 

rhs  is  a  valid  rule  consequent  in  typing  context  T 

[p  HD 

rhr  (r,i:r)f*  r  h  Ihs 

-  rtp_nnc  -  rtp_seq 

r  F  3*  :  r.  rhs  V  F  Ihs 


rhr 


r  is  a  valid  rule  in  typing  context  V 


Cp-Q3 


r  h  Ihs  r  F  rhs 

-  utp_core 

r  F  Ihs  rhs 


Eh  T  (r,i:r)hp 

-  utp_all 

r  h  Mx  :  T.  p 
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r  h  P 

p  is  a  valid  rule  collection  in  typing  context  F 

ip  HD 

Y  h  f  (r,  L  :  r)  h  p 

r  h  r  Y  h  p 

Y  h  ■ 

Y  h  3L  :  r.  p 

r  h  r,p 

Eh  V 

V  is  a  valid  protocol  theory  in  signature  E 

tp  HD 

Eh?  (E,  A  :  principal)  h  p 

-  htp_dot  -  htp_grole 

Eh-  El ~  V,pWA 


(E,  A  :  principal,  E;)  h  V  (E,  A  :  principal,  E;)  h  p 

-  htp_arole 

(E,  A  :  principal,  E;)  h  V,pk 


Eh  R 


R  is  a  valid  active  role  set  in  signature  S 


[p-QU 


E  h  ■ 


atp_dot 


(E,  A  :  principal,  E;)  h  R  (E,  A  :  principal,  E;)  h  p 

-  atp_ext 

(E,  A  :  principal,  E?)  h  R,  pA 


A.3  Data  Access  Specification  Rules 


T;  A  IPA  k  >  A' 

T;  A  IPA  k  >  A' 

r;  a  ihA  t  >  A' 

A  >  e  >  A' 

T;  A  lhA  Ihs  >  F>  A' 


Given  knowledge  A,  principal  A  can  decipher  a  message  encrypted  with  shared  key  k 
in  context  Y 

Given  knowledge  A,  principal  A  can  decipher  a  message  enciypted  with  public  key  k 
in  context  Y 

Given  knowledge  A  and  terms  t,  principal  A  can  knows  A'  in  context  Y 
Merging  context  knowledge  A  and  elementary  term  tuple  e  yields  A' 

Given  knowledge  A,  predicate  sequence  Ihs  and  terms  t,  principal  A  can  knows  A' 
in  context  Y 


[p.|23) 

[p.0 

[p-llD 

[p.[22) 

[p-ED 


r  ‘Ha  e 
r;  a  s->A  t 

T;  A  S^A  t 
r ;  A  S~rA  Ihs 
T;  A  lhA  rhs 


Principal  A  can  access  atomic  information  e  in  context  T  [p.|26| 

Given  knowledge  A,  principal  A  can  construct  term  t  [p.|26| 

Given  knowledge  A,  principal  A  can  construct  term  tuple  t  [p.|26| 

Predicate  sequence  Ihs  is  constructible  from  knowledge  A  for  principal  A  [p.|25| 

Right-hand  side  rhs  implements  valid  data  access  specification  for  principal  A  in  context  T  [p.|25| 

given  knowledge  A 


Y  ll-A  r 

r  ihA  P 

E  Ih  v 
S  lh  R 


Rule  r  implements  valid  data  access  specification  for  principal  A  in  context  T  [p.|19| 

Rule  sequence  p  implements  valid  data  access  specification  for  principal  A  in  context  Y  [p.|19| 

Protocol  theoiy  V  implements  valid  data  access  specification  in  signature  E  [p.|19| 

Active  role  set  R  implements  valid  data  access  specification  in  signature  E  [p.|29| 
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r;  A  IFa  k  >  A' 

Given  knowledge  A,  principal  A  can  decipher  a  message  encrypted  with  shared  key  k  in  context  T 

ip  HD 

-  kac  pus 

(r,  k  :  pubK  B,  r',  k'  :  privK  k,  r");  (A,  k')  IFa  k  >  (A,  k') 

-  kac.puu 

(r,  k  :  pubK  A,  r',  U  :  privK  k,  T");  A  lFA  fc>(A,fe') 

r;  A  IPA  k  »  A' 

Given  knowledge  A,  principal  A  can  decipher  a  message  encrypted  with  public  key  k  in  context  F 

ip-iiJ 

-  kac_ss 

r;(A,fc)  \PA  fc>  {A,k) 


-  kac_sul  -  kac_su2 

(r,  k  :  shK  A  B,  L');  A  IFA  k  >  (A,  k)  (r,  k  :  shK  B  A,  r');  A  IFA  k  >  (A,  k) 


r-  A  IF A  t  »  A' 


Given  knowledge  A  and  terms  t,  principal  A  can  knows  A'  in  context  V 


[pp.  22  27 


r;  a  ihi  • »  a 


r;  (A,  e)  I  Fa  t  >  A' 

-  tac  kn 

T;  (A,  e)  I Fa  e,i>  A' 

T;  A  I  Fa  A' 


(r,e:r,r');(A,e)  (Fa  f»A' 
(r,e:r,r');A  IFa  e,f»  A' 


T;  A  IFa  A' 


L;  A  IFa  A:  »  A'  T;  A'  IFa  t,  t  »  A" 


T;  A  IFa  fc  »  A'  r;  A'  IFa  t,  t  »  A" 


- tac_pke 


r;  A  IFa  {*}*,?»  A" 


r; A  IFa 


>  A" 


r;(A,t)  IFa  r>  a' 


r;(A,i)  IFa  i,t»  A' 


A  >  e  >  A'  A  >  t  >  A' 


Merging  context  knowledge  A  and  (elementary)  term  tuple  e  ( viz ■  t)  yields  A' 


[pp.  22  27 


A  >  •  >  A 


A  >  e  >  A' 

A  >  e,  e  >  (A',  e) 


A  >  e  >  A' 


A  >  t  >  A' 

A  >  t,t  >  (A',t) 


(A,  e)  >  e,e  >  (A',e) 
A  >  t  >  A' 


(A,t)  >  t,t*>  (A',t) 


r;  A  IFa  Ihs  >  t($>  A' 


Given  knowledge  A,  predicate  sequence  Ihs  and  terms  t,  principal  A  can  knows  A' m  context  T 


[pp.  21  27 


A  >  (A,  e )  >  A'  L;  A'  IFa  Ihs  >  t’  >  A" 
r;  A  IFa  (L{A,  e),  Ihs)  >  f  >  A" 

T;  A  IFa  Ihs  >  (t,  t')  »  A' 


-  lac_rsp 


L;  A  IFa  Ihs  >  (t,t‘)  >  A" 
L;  A  IFa  (N (t),lhs)  >f'»  A" 
r;  A  IFa  r>  A' 


L;  A  IFa  (MA(f),  Ihs)  >  t’  >  A'  T;  A  IFA  ■  >  t*>  A' 

A  >  (A,  t)  >  A'  T;  A'  IFa  Ihs  >  t'  >  A" 


T;  A  IFa  (L(A,  t),  Ihs)  >  t'  >  A" 


-  lac_rsp* 


103 


A  COLLECTED  RULES 


THa  e 

Principal  A  can  access  atomic  information  e  in  context  T 

ip  HD 

-  eac.pr 

(L,e  :  principal,  F')  Hm  e 


- eac_sl  - eac_s2 

(L,  e  :  shK  A  B,  C)  ^a  e  (L,  e  :  shK  B  A,  U)  <Ha  e 

-  eac.pp  -  eac_p 

(r,  e  :  privK  k,  T',  k  :  pubK  A,  T")  H>a  e  (L,  e  :  pubK  B,  U)  S^a  e 


T;  A  =Ha  t 


Given  knowledge  A,  principal  A  can  construct  term  t 


[pp.L^LT 


LH-a  e 


T;  (A,  e)  'Ha  e 
r ;  A  S-^a  t\  r ;  A  'Ha  O 


T;  (A,  e)  Hu  e 


-  cac.cnc 


r ;  A  S-A4  ti  £2 


r ;  A  S-u  t  r ;  A  S-u  k 
- ( 

T;  A  Ha  {t}k 


L;  A  Ha  t  r;  A  Ha  k 


L;  A  Ha 


- cac_pke 


L;  (A,£)  Ha  t 


r ;  A  'Ha  t 


Given  knowledge  A,  principal  A  can  construct  term  tuple  t 


[P- 


26 


-  cac_dot 

L;AHa  ■ 


L ;  A  'Ha  t  r;  A  Ha  £ 

-  cac_ext 

LAHa  (t,t) 


r ;  A  S-u  Ihs 


Predicate  sequence  Ihs  is  constructible  from  knowledge  A  for  principal  A 


[p-HD 


-  rac_dot 

T;AHa  ■ 


r;  a  s-^a  t  r;  a  R- >a  ihs 

-  rac_net 

r ;  A  S->a  N  (t ) ,  Ihs 


r;  a  s-^a  t  r;  a  s^a  ihs 

-  rac.mem 

T;  A  'Ha  M A(t),lhs 


I1;  A  Ha  {A,e)  T ;  A  'Ha  Ihs 

-  rac_rsp 

T ;  A  'Ha  L(A,e),  Ihs 


r ;  A  II “a  rhs  Right-hand  side  rhs  implements  valid  data  access  specification  for  principal  A  in  context  T  given  knowledge  A 


[p-HD 


(r,  x  :  nonce);  (A,  x)  IEa  rhs 

-  rac_nnc 

L;  A  Ha  3®  :  nonce,  rhs 


(L,  x  :  msg);  (A,  x)  I  Ha  rhs 

- rac.msg 

T;  A  IHa  3x  :  msg.  rhs 


r ;  A  'Ha  Ihs 
T;  A  ILa  Ihs 


r  I  La  r 


Rule  r  implements  valid  data  access  specification  for  principal  A  in  context  V 


[p-UD 


T;  ■  IHa  Ihs  >  ■  3>  A  L;A  IHa  rhs 

-  uac.core 

T  IHa  Ihs  -A  rhs 


(r,  x  :  t)  IHa  r 

-  uac_all 

r  IHa  V*  :  t.  r 


r  Ha  p 


Rule  sequence  p  implements  valid  data  access  specification  for  principal  A  in  context  F 


[p-UD 


-  oac_dot 

r  Ha  • 


(r,  L  :  r)  Ha  p 

-  oac_rsp 

r  Ha  3 L-.T.p 


r  Ha  r  r  Ha  p 

- oac_rule 

r  Ha  r,p 
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E  lb  V 

Protocol  theory  V  implements  valid  data  access  specification  in  signature  E 

ip  HD 

E  lh  V  (E,  A  :  principal)  lb A  p  E  lb  V  E  lbA  p 

-  hac.dot  -  hue  grolc  -  hac.arole 

E  lb  ■  E  lb  V,pyA  S  lb  P,pA 


E  lb  R 


Active  role  set  R  implements  valid  data  access  specification  in  signature  E 


ip.p) 


E  Ib  R 

S  lbA  p 

-  aac_dot 

;  ib  ■ 

E  Ib 

TD  A 

R,p 

(rhs)s  »  (Ihs) si 

Right-hand  side  instantiation 

tP-HZ) 

r  [»S]  s>[S]s' 

Rule  application 

[p-HD 

V  >  C  — )•  C' 

One-step  sequential  firing 

[p-HD 

P  >  C  —V  C' 

Multi-step  sequential  firing 

[p.[37j 

V  >  C  =>  C' 

One-step  parallel  firing 

[p-HD 

P  >  C  =^*  C' 

Multi-step  parallel  firing 

tp.[D 

A.4  Execution  Rules 


(rhs)s  »  (Ihs) s' 


Right-hand  side  instantiation 


-  sex_seq 

(lhs)s  »  (lhs)s 


{[3 / x\rhs) >  (Ihs)s' 
(3*  :  t.  rhs)s  »  (Ihs)s' 


r  t>  [5]  E  [S  ]  s; 


Rule  application 


E  b  t  :  t  [t/x]r  >  [S]  s  »  [S']  jy 

-  sex_all 

(V*  :  r.  r)  r>  [S]  E  >  [S']  E/ 


(rhs)s  »  (Ihs')s' 

-  sexcore 

( Ihs  — >  rhs)  >  [S',  Ihs]  s  >>  [S,  Ihs']  s/ 


V  >  C  — >  C 


One-step  sequential  firing 


[P  |36| 


E  b  A  :  principal 


(7>,P>  [S]g  — ►  [S]*'" 


(V,pVA)>  [S]g  — i-  [5]«b[A/A]p)A 


■  sex_grole 


rt>  ['S']  £  ^  [S  ]  E' 


Vt>  [S]«'(3^-a)a 


rci  #>([ li/l]p)a 
PJ  (S,L;:r) 


V>  [S]2’Cr,p)A 


[S']«;(A)A 


P>  [S]E’(r’A)A  — ^  [S]s’(a)A 


-  sex_skp 


[S]«’«A  — ►  [S] 


V  >  c  — >*  c 


Multi-step  sequential  firing 


Ip-LZ) 


V  >  C  — >  C'  V  >  C 


V  >  C  — ►*  c 


v>  c 
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V  >  C  =>  C' 

One-step  parallel  firing 

[p  HD 

[5l]«i  [^]giEl)  V>  [S2]*2  =►  $ 

r'2 

(E,E') 

-  pex_id 

V\ >  c  =>  c 

Vt>  [Si,s2](*1,a*)  => 

r  o'  o'  1  (^i  ’^2) 
L^l?  °2j  (53,2' ,H') 

V>  C  =>*  C' 

Multi-step  parallel  firing 

Ip  HU 

Vi >  C  =>  C' 

Vi >  C'  =>*  c" 

pex_itn 

r>  c  =>*  c 

V\>  C 

=^*  c" 
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